Access backup

"a a r o n . k e m p f @ g m a i l . c o m" wrote in
message


> Jet can't handle a half dozen users
> and a mere 25mb of data without crashes and bloat
-------------------------------------------

Once again. If you'd learn how to design and maintain a database, you would
never have a problem with crashes or bloat. Jet can easily handle dozens of
users with hundreds of MBs of data. If you want a demonstration, I'd be
happy to give you one, but since they will no longer let you on the
Microsoft campus, that's unlikely.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com
 >> Stay informed about: Access backup 

Look dude-- I don't need to use a platform that crashes and hangs with
a trivial amount of data.

In Microsoft's own words....
The following comes from Microsoft article Q300216.

-----------------------------------------------------------------------------------------------------------------------------------------------------------
"Microsoft Jet is a file-sharing database system. A file-sharing
database is one in which all the processing of the file
takes place at the client. When a file-sharing database, such as
Microsoft Jet, is used in a multiuser environment,
multiple client processes are using file read, write, and locking
operations on the same shared file across a network. If,
for any reason, a process cannot be completed, the file can be left in
an incomplete or a corrupted state. Two
examples of when a process may not be completed is when a client is
terminated unexpectedly or when a network
connection to a server is dropped.

Microsoft Jet is not intended to be used with high-stress, high-
concurrency, 24x7 server applications, such as Web,
commerce, transactional, and messaging servers. For these type of
applications, the best solution is to switch to a true
client/server-based database system such as Microsoft Data Engine
(MSDE) or Microsoft SQL Server. When you use
Microsoft Jet in high-stress applications such as Microsoft Internet
Information Server (IIS), customers have reported
database corruption, stability issues such as IIS crashing or locking
up, and also a sudden and persistent failure of the
driver to connect to a valid database that requires re-starting the
IIS service."
-----------------------------------------------------------------------------------------------------------------------------------------------------------


On Dec 30, 3:52 pm, "Arvin Meyer [MVP]" wrote:
> "a a r o n . k e m p f @ g m a i l . c o m" wrote in
> messagenews:99ba7757-b9ef-4d0f-99e6-620ae4d4fd34@n33g2000pri.googlegroups..com...
>
> > Jet can't handle a half dozen users
> > and a mere 25mb of data without crashes and bloat
>
> -------------------------------------------
>
> Once again. If you'd learn how to design and maintain a database, you would
> never have a problem with crashes or bloat. Jet can easily handle dozens of
> users with hundreds of MBs of data. If you want a demonstration, I'd be
> happy to give you one, but since they will no longer let you on the
> Microsoft campus, that's unlikely.
> --
> Arvin Meyer, MCP, MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com
 >> Stay informed about: Access backup 

I agree that all C&R should be avoided.

Move to SQL Server and seperate your _DATA_ from your _APPLICATION_.






On Dec 30, 8:07 am, "BruceM" wrote:
> You could end up with the same problem with a manual C&R, but at least you
> will see it at the time.  That being said, I agree that automatic C&R should
> be avoided.
>
> "Nona" wrote in message
>
>
>
>
>
> > My suggestion, learned in these discussion groups, is to uncheck the
> > option
> > to automatically Compact and Repair upon closing the database. You can
> > manually compact as often as you think necessary, but I can almost
> > guarantee
> > that you won't get the copies named db1, db2, etc. if you uncheck this
> > option. At least this worked for me!
> > --
> > Nona
>
> > "BruceM" wrote:
>
> >> As I recall, automatic C&R is performed only when the last user exits the
> >> database, so the problems can't be the result of several users doing C&R
> >> at
> >> the same time.  The C&R process can fail for any number of reasons, but
> >> the
> >> db1 etc. file often functions well enough as a substitute for the
> >> original
> >> that it may seem the only difference is the name.
>
> >> "Ron" wrote in message
> >>
> >> On Dec 28, 4:45 pm, Martin wrote:
> >> > In our office we have our Access database saved on a server. Four
> >> > people
> >> > use
> >> > this database. Each person has a shortcut on their desktop to open the
> >> > database. No-one tells the database to backup--but every once in a
> >> > while
> >> > it
> >> > backs up on its own and names the backups db1.mdb, db2.mdb etc. How do
> >> > we
> >> > get this automatic backup to stop?
> >> > When an automatic backup is made, new shortcuts to the newest backup
> >> > need
> >> > to
> >> > be made.
>
> >> WARNING:  I'm NOT an MVP so "the regulars" here have probably
> >> forgotten more about Access than I know at this point.  But...
>
> >> I've looked at all the responses and it seems to me that everyone has
> >> overlooked something.  The OP said they're changing the shortcuts to
> >> the database (in order to use it, add records etc I would assume) to
> >> this new db1 or db2 or whatever.
>
> >> Number 1, that's not what a "backup" is for.  You don't use the
> >> backup.  It's for use only if there's a problem with the original
> >> file.  The original file (with whatever name it had originally) should
> >> be the datafile you're users are using, adding to, modifying, etc.
>
> >> So, to me, it appears you have "incremental" backups (because each
> >> time someone triggers the automatic C & R, it renames it db##.mdb and
> >> everyone switches to that one via their shortcuts) that you're then
> >> switching to and using as your main datafile.  Because the compact and
> >> repair operation couldn't do it's work (because another user had the
> >> same file open) isn't this db#.mdb suspect as far as accuracy?  After
> >> all, the reason the C & R couldn't do it's job is because someone else
> >> is using the database, perhaps adding or modifying a record--so
> >> wouldn't that mean the recently added, changed data might not be
> >> included in the new db##.mdb?
>
> >> Me thinks the original poster may have more problems than just the
> >> naming and shortcuts to the file they're using.  Perhaps?
>
> >> ron- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: Access backup 

The title to which Aaron refers to is:

How to keep a Jet 4.0 database in top working condition in Access 2000

Link: http://support.microsoft.com/kb/300216

Maybe you could find something more recent and pertinent?
Gina Whipp

"I feel I have been denied critical, need to know, information!" - Tremors
II


"a a r o n . k e m p f @ g m a i l . c o m" wrote in
message

Look dude-- I don't need to use a platform that crashes and hangs with
a trivial amount of data.

In Microsoft's own words....
The following comes from Microsoft article Q300216.

-----------------------------------------------------------------------------------------------------------------------------------------------------------
"Microsoft Jet is a file-sharing database system. A file-sharing
database is one in which all the processing of the file
takes place at the client. When a file-sharing database, such as
Microsoft Jet, is used in a multiuser environment,
multiple client processes are using file read, write, and locking
operations on the same shared file across a network. If,
for any reason, a process cannot be completed, the file can be left in
an incomplete or a corrupted state. Two
examples of when a process may not be completed is when a client is
terminated unexpectedly or when a network
connection to a server is dropped.

Microsoft Jet is not intended to be used with high-stress, high-
concurrency, 24x7 server applications, such as Web,
commerce, transactional, and messaging servers. For these type of
applications, the best solution is to switch to a true
client/server-based database system such as Microsoft Data Engine
(MSDE) or Microsoft SQL Server. When you use
Microsoft Jet in high-stress applications such as Microsoft Internet
Information Server (IIS), customers have reported
database corruption, stability issues such as IIS crashing or locking
up, and also a sudden and persistent failure of the
driver to connect to a valid database that requires re-starting the
IIS service."
-----------------------------------------------------------------------------------------------------------------------------------------------------------


On Dec 30, 3:52 pm, "Arvin Meyer [MVP]" wrote:
> "a a r o n . k e m p f @ g m a i l . c o m" wrote
> in
> messagenews:99ba7757-b9ef-4d0f-99e6-620ae4d4fd34@n33g2000pri.googlegroups.com...
>
> > Jet can't handle a half dozen users
> > and a mere 25mb of data without crashes and bloat
>
> -------------------------------------------
>
> Once again. If you'd learn how to design and maintain a database, you
> would
> never have a problem with crashes or bloat. Jet can easily handle dozens
> of
> users with hundreds of MBs of data. If you want a demonstration, I'd be
> happy to give you one, but since they will no longer let you on the
> Microsoft campus, that's unlikely.
> --
> Arvin Meyer, MCP,
> MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com
 >> Stay informed about: Access backup 

I didn't say all C&R should be avoided, just that automatic C&R can lead to
problems. I do split the data from the application. When I do additional
work on the FE I do C&R before deploying the new FE.

"a a r o n . k e m p f @ g m a i l . c o m" wrote in
message

I agree that all C&R should be avoided.

Move to SQL Server and seperate your _DATA_ from your _APPLICATION_.






On Dec 30, 8:07 am, "BruceM" wrote:
> You could end up with the same problem with a manual C&R, but at least you
> will see it at the time. That being said, I agree that automatic C&R
> should
> be avoided.
>
> "Nona" wrote in message
>
>
>
>
>
> > My suggestion, learned in these discussion groups, is to uncheck the
> > option
> > to automatically Compact and Repair upon closing the database. You can
> > manually compact as often as you think necessary, but I can almost
> > guarantee
> > that you won't get the copies named db1, db2, etc. if you uncheck this
> > option. At least this worked for me!
> > --
> > Nona
>
> > "BruceM" wrote:
>
> >> As I recall, automatic C&R is performed only when the last user exits
> >> the
> >> database, so the problems can't be the result of several users doing
> >> C&R
> >> at
> >> the same time. The C&R process can fail for any number of reasons, but
> >> the
> >> db1 etc. file often functions well enough as a substitute for the
> >> original
> >> that it may seem the only difference is the name.
>
> >> "Ron" wrote in message
> >>
> >> On Dec 28, 4:45 pm, Martin wrote:
> >> > In our office we have our Access database saved on a server. Four
> >> > people
> >> > use
> >> > this database. Each person has a shortcut on their desktop to open
> >> > the
> >> > database. No-one tells the database to backup--but every once in a
> >> > while
> >> > it
> >> > backs up on its own and names the backups db1.mdb, db2.mdb etc. How
> >> > do
> >> > we
> >> > get this automatic backup to stop?
> >> > When an automatic backup is made, new shortcuts to the newest backup
> >> > need
> >> > to
> >> > be made.
>
> >> WARNING: I'm NOT an MVP so "the regulars" here have probably
> >> forgotten more about Access than I know at this point. But...
>
> >> I've looked at all the responses and it seems to me that everyone has
> >> overlooked something. The OP said they're changing the shortcuts to
> >> the database (in order to use it, add records etc I would assume) to
> >> this new db1 or db2 or whatever.
>
> >> Number 1, that's not what a "backup" is for. You don't use the
> >> backup. It's for use only if there's a problem with the original
> >> file. The original file (with whatever name it had originally) should
> >> be the datafile you're users are using, adding to, modifying, etc.
>
> >> So, to me, it appears you have "incremental" backups (because each
> >> time someone triggers the automatic C & R, it renames it db##.mdb and
> >> everyone switches to that one via their shortcuts) that you're then
> >> switching to and using as your main datafile. Because the compact and
> >> repair operation couldn't do it's work (because another user had the
> >> same file open) isn't this db#.mdb suspect as far as accuracy? After
> >> all, the reason the C & R couldn't do it's job is because someone else
> >> is using the database, perhaps adding or modifying a record--so
> >> wouldn't that mean the recently added, changed data might not be
> >> included in the new db##.mdb?
>
> >> Me thinks the original poster may have more problems than just the
> >> naming and shortcuts to the file they're using. Perhaps?
>
> >> ron- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: Access backup 

"a a r o n . k e m p f @ g m a i l . c o m" wrote in
message


Move to SQL Server and seperate your _DATA_ from your _APPLICATION_.

It doesn't matter which engine you use, data should always be separated from
the application, especially if there is more than one user or the data is on
a server.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com






On Dec 30, 8:07 am, "BruceM" wrote:
> You could end up with the same problem with a manual C&R, but at least you
> will see it at the time. That being said, I agree that automatic C&R
> should
> be avoided.
>
> "Nona" wrote in message
>
>
>
>
>
> > My suggestion, learned in these discussion groups, is to uncheck the
> > option
> > to automatically Compact and Repair upon closing the database. You can
> > manually compact as often as you think necessary, but I can almost
> > guarantee
> > that you won't get the copies named db1, db2, etc. if you uncheck this
> > option. At least this worked for me!
> > --
> > Nona
>
> > "BruceM" wrote:
>
> >> As I recall, automatic C&R is performed only when the last user exits
> >> the
> >> database, so the problems can't be the result of several users doing
> >> C&R
> >> at
> >> the same time. The C&R process can fail for any number of reasons, but
> >> the
> >> db1 etc. file often functions well enough as a substitute for the
> >> original
> >> that it may seem the only difference is the name.
>
> >> "Ron" wrote in message
> >>
> >> On Dec 28, 4:45 pm, Martin wrote:
> >> > In our office we have our Access database saved on a server. Four
> >> > people
> >> > use
> >> > this database. Each person has a shortcut on their desktop to open
> >> > the
> >> > database. No-one tells the database to backup--but every once in a
> >> > while
> >> > it
> >> > backs up on its own and names the backups db1.mdb, db2.mdb etc. How
> >> > do
> >> > we
> >> > get this automatic backup to stop?
> >> > When an automatic backup is made, new shortcuts to the newest backup
> >> > need
> >> > to
> >> > be made.
>
> >> WARNING: I'm NOT an MVP so "the regulars" here have probably
> >> forgotten more about Access than I know at this point. But...
>
> >> I've looked at all the responses and it seems to me that everyone has
> >> overlooked something. The OP said they're changing the shortcuts to
> >> the database (in order to use it, add records etc I would assume) to
> >> this new db1 or db2 or whatever.
>
> >> Number 1, that's not what a "backup" is for. You don't use the
> >> backup. It's for use only if there's a problem with the original
> >> file. The original file (with whatever name it had originally) should
> >> be the datafile you're users are using, adding to, modifying, etc.
>
> >> So, to me, it appears you have "incremental" backups (because each
> >> time someone triggers the automatic C & R, it renames it db##.mdb and
> >> everyone switches to that one via their shortcuts) that you're then
> >> switching to and using as your main datafile. Because the compact and
> >> repair operation couldn't do it's work (because another user had the
> >> same file open) isn't this db#.mdb suspect as far as accuracy? After
> >> all, the reason the C & R couldn't do it's job is because someone else
> >> is using the database, perhaps adding or modifying a record--so
> >> wouldn't that mean the recently added, changed data might not be
> >> included in the new db##.mdb?
>
> >> Me thinks the original poster may have more problems than just the
> >> naming and shortcuts to the file they're using. Perhaps?
>
> >> ron- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: Access backup 

Arvin;

but-- on the other hand-- THREE TIERS of jet is called unnecessary






On Dec 31 2008, 9:02 pm, "Arvin Meyer [MVP]"
wrote:
> "a a r o n . k e m p f @ g m a i l . c o m" wrote in
> messagenews:af9946a6-e93f-4e83-bcb0-91e3dae15b66@y1g2000pra.googlegroups.com...
>
> Move to SQL Server and seperate your _DATA_ from your _APPLICATION_.
>
> It doesn't matter which engine you use, data should always be separated from
> the application, especially if there is more than one user or the data is on
> a server.
> --
> Arvin Meyer, MCP, MVPhttp://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com
>
> On Dec 30, 8:07 am, "BruceM" wrote:
>
>
>
> > You could end up with the same problem with a manual C&R, but at least you
> > will see it at the time. That being said, I agree that automatic C&R
> > should
> > be avoided.
>
> > "Nona" wrote in message
>
> >
>
> > > My suggestion, learned in these discussion groups, is to uncheck the
> > > option
> > > to automatically Compact and Repair upon closing the database. You can
> > > manually compact as often as you think necessary, but I can almost
> > > guarantee
> > > that you won't get the copies named db1, db2, etc. if you uncheck this
> > > option. At least this worked for me!
> > > --
> > > Nona
>
> > > "BruceM" wrote:
>
> > >> As I recall, automatic C&R is performed only when the last user exits
> > >> the
> > >> database, so the problems can't be the result of several users doing
> > >> C&R
> > >> at
> > >> the same time. The C&R process can fail for any number of reasons, but
> > >> the
> > >> db1 etc. file often functions well enough as a substitute for the
> > >> original
> > >> that it may seem the only difference is the name.
>
> > >> "Ron" wrote in message
> > >>
> > >> On Dec 28, 4:45 pm, Martin wrote:
> > >> > In our office we have our Access database saved on a server. Four
> > >> > people
> > >> > use
> > >> > this database. Each person has a shortcut on their desktop to open
> > >> > the
> > >> > database. No-one tells the database to backup--but every once in a
> > >> > while
> > >> > it
> > >> > backs up on its own and names the backups db1.mdb, db2.mdb etc. How
> > >> > do
> > >> > we
> > >> > get this automatic backup to stop?
> > >> > When an automatic backup is made, new shortcuts to the newest backup
> > >> > need
> > >> > to
> > >> > be made.
>
> > >> WARNING: I'm NOT an MVP so "the regulars" here have probably
> > >> forgotten more about Access than I know at this point. But...
>
> > >> I've looked at all the responses and it seems to me that everyone has
> > >> overlooked something. The OP said they're changing the shortcuts to
> > >> the database (in order to use it, add records etc I would assume) to
> > >> this new db1 or db2 or whatever.
>
> > >> Number 1, that's not what a "backup" is for. You don't use the
> > >> backup. It's for use only if there's a problem with the original
> > >> file. The original file (with whatever name it had originally) should
> > >> be the datafile you're users are using, adding to, modifying, etc.
>
> > >> So, to me, it appears you have "incremental" backups (because each
> > >> time someone triggers the automatic C & R, it renames it db##.mdb and
> > >> everyone switches to that one via their shortcuts) that you're then
> > >> switching to and using as your main datafile. Because the compact and
> > >> repair operation couldn't do it's work (because another user had the
> > >> same file open) isn't this db#.mdb suspect as far as accuracy? After
> > >> all, the reason the C & R couldn't do it's job is because someone else
> > >> is using the database, perhaps adding or modifying a record--so
> > >> wouldn't that mean the recently added, changed data might not be
> > >> included in the new db##.mdb?
>
> > >> Me thinks the original poster may have more problems than just the
> > >> naming and shortcuts to the file they're using. Perhaps?
>
> > >> ron- Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
 >> Stay informed about: Access backup