|
|
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.
|
|
This is actually more likely to be a result of one or more incomplete
"Compact and Repair" attempts by the database. If an attempt is made to C&R
a database which another user has open, the C&R can't complete and leaves
the temporary db named "db1.mdb" behind. Of course, if it happens again and
there is already an orphaned db1.mdb, then the C&R calls the new temp
db2.mdb and so on.
It does no harm to delete these temp mdbs, but be careful not to mess with
the production mdb itself.
Do you, by any chance, have the option to "Compact and Repair on Close" set
for this database?
On a related note, are all of your users working with a single mdb? Do you
NOT have a split design in place? A split design involves a separate mdb,
usually referred to as the "back end", in which only the tables for your
data reside. In a separate "front end", you should have all of the remaining
objects--forms, queries, reports, code modules and macros.
Each user should have and USE their own copy of the Front End. That
minimizes the problems caused by multiple users working with a single mdb
file.
Letting multiple users work with a single mdb is an open inventation to
corruption.
Search for articles on "Split Database" for more information.
"Martin" <Martin[ at ]discussions.microsoft.com> wrote in message
news:E51710F6-1C39-40F3-A91A-8617E273357D[ at ]microsoft.com...
[Quoted Text] > 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.
|
|
On Sun, 28 Dec 2008 16:45:00 -0800, Martin <Martin[ at ]discussions.microsoft.com>
wrote:
Urgent warning: Split your database, *now*. Sharing a single mdb among
multiple users can and will cause bloat, bad performance, and an increased
risk of corruption. Each user should have their own individual copy of a
"frontend" containing the Forms, Queries, Reports, etc., linked to a shared
Backend containing the tables. See
http://www.granite.ab.ca/access/splitapp.htm for a thorough discussion.
[Quoted Text] >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?
Turn off Auto Compact. It's not really a backup other than in a manner of
speaking; Compacting works by copying the database to db1.mdb (or 2 or 3...),
deleting the old database and renaming the new one back to the original name.
>When an automatic backup is made, new shortcuts to the newest backup need to
>be made.
Why? I'd just keep a separate backup, independent of the compaction process.
--
John W. Vinson [MVP]
|
|
"Martin" <Martin[ at ]discussions.microsoft.com> wrote in message
news:E51710F6-1C39-40F3-A91A-8617E273357D[ at ]microsoft.com...
[Quoted Text] > 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.
In addition to what the others have said, all of which is extremely
important, you should be regularly backing up the data and a copy of the
front-end which should live on the server to replace the local desktop
front-end should it become necessary. Daily incremental backup should be
done, and the entire server should be backed up at least weekly.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com
|
|
you actually CANNOT back the data up when someone has it open.
This is just another symptom that Jet databases don't fit the needs of
MOST businesses.
On Dec 28, 4:45 pm, Martin <Mar...[ at ]discussions.microsoft.com> wrote:
[Quoted Text] > 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.
|
|
Urgent warning: Upsize your database, *now*. Sharing a any type of Jet
database among
multiple users can and will cause bloat, bad performance, and an
increased
risk of corruption. Each user should have their own individual copy of
an ADP
"frontend" containing the Forms, Reports, etc., linked to a single
shared connection to a
SQL Server Backend containing the tables.
See www.microsoft.com/sql
On Dec 28, 4:59 pm, John W. Vinson
<jvinson[ at ]STOP_SPAM.WysardOfInfo.com> wrote:
[Quoted Text] > On Sun, 28 Dec 2008 16:45:00 -0800, Martin <Mar...[ at ]discussions.microsoft.com> > wrote: > > Urgent warning: Split your database, *now*. Sharing a single mdb among > multiple users can and will cause bloat, bad performance, and an increased > risk of corruption. Each user should have their own individual copy of a > "frontend" containing the Forms, Queries, Reports, etc., linked to a shared > Backend containing the tables. See http://www.granite.ab.ca/access/splitapp.htmfor a thorough discussion. > > >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? > > Turn off Auto Compact. It's not really a backup other than in a manner of > speaking; Compacting works by copying the database to db1.mdb (or 2 or 3....), > deleting the old database and renaming the new one back to the original name. > > >When an automatic backup is made, new shortcuts to the newest backup need to > >be made. > > Why? I'd just keep a separate backup, independent of the compaction process. > -- > > John W. Vinson [MVP]
|
|
Please ignore Aaron. He is incorrect about Jet in a multi-user environment.
AFAIK it is possible to back up a Jet back end file that is in use, but
there may be nuances of which I am unaware..
"Martin" <Martin[ at ]discussions.microsoft.com> wrote in message
news:E51710F6-1C39-40F3-A91A-8617E273357D[ at ]microsoft.com...
[Quoted Text] > 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.
|
|
Bruce;
So sorry that you've never had to backup a Jet database.
Please explain to me how it works, because I've had corruption
failures on busy jet databases _ALL_ the time
On Dec 29, 4:27 am, "BruceM" <bam...[ at ]yawhodotcalm.not> wrote:
[Quoted Text] > Please ignore Aaron. He is incorrect about Jet in a multi-user environment.
> AFAIK it is possible to back up a Jet back end file that is in use, but
> there may be nuances of which I am unaware..
>
> "Martin" <Mar...[ at ]discussions.microsoft.com> wrote in message
>
> news:E51710F6-1C39-40F3-A91A-8617E273357D[ at ]microsoft.com...
>
>
>
> > 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.- Hide quoted text -
>
> - Show quoted text -
|
|
There is a daily network backup. The BE files are on the network. I
couldn't say for sure that the BE files are never in use during the backup,
but I do know there have been no corruption problems. I do know that in
order to have a test copy of the data I have copied BE files from working
databases, and have not had problems.
Quite a remarkable thing that you have failures all the time with a product
you never use.
"a a r o n . k e m p f [ at ] g m a i l . c o m" <aaron.kempf[ at ]gmail.com> wrote in
message
news:e9c24262-faa0-414b-bf78-76fc14b88ac4[ at ]e1g2000pra.googlegroups.com...
Bruce;
So sorry that you've never had to backup a Jet database.
Please explain to me how it works, because I've had corruption
failures on busy jet databases _ALL_ the time
On Dec 29, 4:27 am, "BruceM" <bam...[ at ]yawhodotcalm.not> wrote:
[Quoted Text] > Please ignore Aaron. He is incorrect about Jet in a multi-user
> environment.
> AFAIK it is possible to back up a Jet back end file that is in use, but
> there may be nuances of which I am unaware..
>
> "Martin" <Mar...[ at ]discussions.microsoft.com> wrote in message
>
> news:E51710F6-1C39-40F3-A91A-8617E273357D[ at ]microsoft.com...
>
>
>
> > 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.- Hide quoted text -
>
> - Show quoted text -
|
|
On Dec 28, 4:45 pm, Martin <Mar...[ at ]discussions.microsoft.com> wrote:
[Quoted Text] > 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
|
|
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" <ronwest777[ at ]gmail.com> wrote in message
news:ebc0711a-a65b-4512-8f3f-d826b461398e[ at ]c36g2000prc.googlegroups.com...
On Dec 28, 4:45 pm, Martin <Mar...[ at ]discussions.microsoft.com> wrote:
[Quoted Text] > 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
|
|
"a a r o n . k e m p f [ at ] g m a i l . c o m" <aaron.kempf[ at ]gmail.com>
wrote:
[Quoted Text] >Urgent warning: Upsize your database, *now*. Sharing a any type of Jet
>database among
>multiple users can and will cause bloat, bad performance, and an
>increased
>risk of corruption.
False.
>Each user should have their own individual copy of
>an ADP
>"frontend" containing the Forms, Reports, etc., linked to a single
>shared connection to a
>SQL Server Backend containing the tables.
Almost always quite impractical.
Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
|
|
On Mon, 29 Dec 2008 06:49:55 -0800 (PST), "a a r o n . k e m p f [ at ] g m
a i l . c o m" <aaron.kempf[ at ]gmail.com> wrote:
[Quoted Text] >Please explain to me how it works, because I've had corruption
>failures on busy jet databases _ALL_ the time
Why do you still use it "_ALL_ the time"?
I thought you didn't like it?
Why don't you switch to SQL?
|
|
"BruceM" <bamoob[ at ]yawhodotcalm.not> wrote in
news:ucEkXDbaJHA.1184[ at ]TK2MSFTNGP05.phx.gbl:
[Quoted Text] > Please ignore Aaron. He is incorrect about Jet in a multi-user
> environment.
You could more correctly say about Aaron:
He is incorrect on virtually any subject he chooses to "address."
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
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:
[Quoted Text] > 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" <ronwest777[ at ]gmail.com> wrote in message
> news:ebc0711a-a65b-4512-8f3f-d826b461398e[ at ]c36g2000prc.googlegroups.com...
> On Dec 28, 4:45 pm, Martin <Mar...[ at ]discussions.microsoft.com> 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
>
>
|
|
Impractical?
I'd bet that 90% of the people here would prefer a platform that
_NEVER_ crashes--
_NEVER_ bloats..
where maintenance is automatic,
performance is better,
it's faster
**and **
easier development?
On Dec 29, 12:23 pm, "Tony Toews [MVP]" <tto...[ at ]telusplanet.net>
wrote:
[Quoted Text] > "a a r o n . k e m p f [ at ] g m a i l . c o m" <aaron.ke...[ at ]gmail.com> > wrote: > > >Urgent warning: Upsize your database, *now*. Sharing a any type of Jet > >database among > >multiple users can and will cause bloat, bad performance, and an > >increased > >risk of corruption. > > False. > > >Each user should have their own individual copy of > >an ADP > >"frontend" containing the Forms, Reports, etc., linked to a single > >shared connection to a > >SQL Server Backend containing the tables. > > Almost always quite impractical. > > Tony > -- > Tony Toews, Microsoft Access MVP > Please respond only in the newsgroups so that others can > read the entire thread of messages. > Microsoft Access Links, Hints, Tips & Accounting Systems at http://www.granite.ab.ca/accsmstr.htm> Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
|
|
David is incorrect.
It's not appropriate for _ANYONE_ and it's not appropriate for
_EVERYONE_.
Jet is crap, it crashes, it bloats-- most people in the real world
know better-- they moved to SQL Server a long time ago
Jet can't handle a half dozen users
and a mere 25mb of data without crashes and bloat
On Dec 29, 5:28 pm, "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid>
wrote:
[Quoted Text] > "BruceM" <bam...[ at ]yawhodotcalm.not> wrote innews:ucEkXDbaJHA.1184[ at ]TK2MSFTNGP05.phx.gbl: > > > Please ignore Aaron. He is incorrect about Jet in a multi-user > > environment. > > You could more correctly say about Aaron: > > He is incorrect on virtually any subject he chooses to "address." > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
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" <Nona[ at ]discussions.microsoft.com> wrote in message
news:933CFC74-DE7F-49A7-97A5-67BC9367B88C[ at ]microsoft.com...
[Quoted Text] > 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" <ronwest777[ at ]gmail.com> wrote in message
>> news:ebc0711a-a65b-4512-8f3f-d826b461398e[ at ]c36g2000prc.googlegroups.com...
>> On Dec 28, 4:45 pm, Martin <Mar...[ at ]discussions.microsoft.com> 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
>>
>>
|
|
Still wrong about the 25mb limit or the number of users. It is a matter of
proper database design. If you are having problems you should look there.
"a a r o n . k e m p f [ at ] g m a i l . c o m" <aaron.kempf[ at ]gmail.com> wrote in
message
news:99ba7757-b9ef-4d0f-99e6-620ae4d4fd34[ at ]n33g2000pri.googlegroups.com...
David is incorrect.
It's not appropriate for _ANYONE_ and it's not appropriate for
_EVERYONE_.
Jet is crap, it crashes, it bloats-- most people in the real world
know better-- they moved to SQL Server a long time ago
Jet can't handle a half dozen users
and a mere 25mb of data without crashes and bloat
On Dec 29, 5:28 pm, "David W. Fenton" <XXXuse...[ at ]dfenton.com.invalid>
wrote:
[Quoted Text] > "BruceM" <bam...[ at ]yawhodotcalm.not> wrote > innews:ucEkXDbaJHA.1184[ at ]TK2MSFTNGP05.phx.gbl: > > > Please ignore Aaron. He is incorrect about Jet in a multi-user > > environment. > > You could more correctly say about Aaron: > > He is incorrect on virtually any subject he chooses to "address." > > -- > David W. Fenton http://www.dfenton.com/> usenet at dfenton dot com http://www.dfenton.com/DFA/
|
|
"a a r o n . k e m p f [ at ] g m a i l . c o m" <aaron.kempf[ at ]gmail.com> wrote in
message
news:99ba7757-b9ef-4d0f-99e6-620ae4d4fd34[ at ]n33g2000pri.googlegroups.com...
[Quoted Text] > 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
|
|
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]" <arv...[ at ]mvps.invalid> wrote:
[Quoted Text] > "a a r o n . k e m p f [ at ] g m a i l . c o m" <aaron.ke...[ at ]gmail.com> wrote in > messagenews:99ba7757-b9ef-4d0f-99e6-620ae4d4fd34[ at ]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, MVP http://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com
|
|
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" <bam...[ at ]yawhodotcalm.not> wrote:
[Quoted Text] > 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" <N...[ at ]discussions.microsoft.com> wrote in message
>
> news:933CFC74-DE7F-49A7-97A5-67BC9367B88C[ at ]microsoft.com...
>
>
>
> > 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" <ronwest...[ at ]gmail.com> wrote in message
> >>news:ebc0711a-a65b-4512-8f3f-d826b461398e[ at ]c36g2000prc.googlegroups.com....
> >> On Dec 28, 4:45 pm, Martin <Mar...[ at ]discussions.microsoft.com> 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 -
|
|
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 [ at ] g m a i l . c o m" <aaron.kempf[ at ]gmail.com> wrote in
message
news:bbf28b6a-19b1-4485-8599-1ae6b2a66b6f[ at ]o4g2000pra.googlegroups.com...
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]" <arv...[ at ]mvps.invalid> wrote:
[Quoted Text] > "a a r o n . k e m p f [ at ] g m a i l . c o m" <aaron.ke...[ at ]gmail.com> wrote > in > messagenews:99ba7757-b9ef-4d0f-99e6-620ae4d4fd34[ at ]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, > MVP http://www.datastrat.comhttp://www.mvps.org/accesshttp://www.accessmvp.com
|
|
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 [ at ] g m a i l . c o m" <aaron.kempf[ at ]gmail.com> wrote in
message
news:af9946a6-e93f-4e83-bcb0-91e3dae15b66[ at ]y1g2000pra.googlegroups.com...
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" <bam...[ at ]yawhodotcalm.not> wrote:
[Quoted Text] > 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" <N...[ at ]discussions.microsoft.com> wrote in message
>
> news:933CFC74-DE7F-49A7-97A5-67BC9367B88C[ at ]microsoft.com...
>
>
>
> > 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" <ronwest...[ at ]gmail.com> wrote in message
> >>news:ebc0711a-a65b-4512-8f3f-d826b461398e[ at ]c36g2000prc.googlegroups.com...
> >> On Dec 28, 4:45 pm, Martin <Mar...[ at ]discussions.microsoft.com> 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 -
|
|
"a a r o n . k e m p f [ at ] g m a i l . c o m" <aaron.kempf[ at ]gmail.com> wrote in
message
news:af9946a6-e93f-4e83-bcb0-91e3dae15b66[ at ]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, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com
On Dec 30, 8:07 am, "BruceM" <bam...[ at ]yawhodotcalm.not> wrote:
[Quoted Text] > 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" <N...[ at ]discussions.microsoft.com> wrote in message
>
> news:933CFC74-DE7F-49A7-97A5-67BC9367B88C[ at ]microsoft.com...
>
>
>
> > 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" <ronwest...[ at ]gmail.com> wrote in message
> >>news:ebc0711a-a65b-4512-8f3f-d826b461398e[ at ]c36g2000prc.googlegroups.com...
> >> On Dec 28, 4:45 pm, Martin <Mar...[ at ]discussions.microsoft.com> 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 -
|
|
|