Multi user problems on a unix network (97/SR2)

Topic

New Reply

Just crying out some frustration… as probably no-one will have an appropriate help for this one…

I started at a new job. There, a simple Access-file (2 linked tables, query, form & subform, 300 & 600 records) turned strangely enough nuts after having been used for maybe a few days:

– an innocent collegue-user which entered the data, suddenly got a message about duplicate key field values in the (autonumber) ID field
=> reason: autonumber restarted at once, numbering at a lower number
(we got it solved by entering some data in a new record & (instead of saving/moving to another record) pressing escape twice to ‘undo’ & making Access ‘loose’ the current number in it’s autonumbering process, untill autonumber finally re-arrived at the last used number)

– a short while later, the form & database got corrupt, sending messages which normally only appear when you try to open an Access2000 file with Access97: unknown database format, etc. Database repair didn’t work – suddenly worked once producing a file that soon got corrupt AGAIN and then, we gave up & started again with a backup.
(it worked fine for about a week, then)

– irritatingly & inconsistent restricted access to queries and tables
e.g. Access refuses to open linked tables & (also in the same session created & for some seconds working) queries with an error like (translated from Dutch) “Microsoft Jet Engine stopped the process because you and another user tried to edit the same data”
e.g. All record locking,… properties & options are set ‘multi-user’. Still, when the database is already opened by another user, other users only get access after trying opening the file twice. The first time, they’re warned that “The table MSysModules2 is exclusively opened by another user or opened by means of the interface and can’t be manipulated by the program”.

I don’t know what to expect next, but you can imagine that this doesn’t invite to using my most beloved database development tool much longer…
More: elder collegues, experienced from a previous project, told that their application tended to crash weekly/… – only regular backup helped. They told that even when the file is accessed by different users on different times, problems remain. So the problems ended… when Access use ended…
More: I attended the helpdesk of the company supporting the IT around here. Their advice: don’t use Access. The replacement of the network isn’t planned for the near future. And that seems to be a regular advise here.

BEFORE I ‘m forced to move to (and start learning) Filemaker pro or whatever… (if that helps…)
=> does anyone have had the same experience?
=> does anyone have a solution?

Hans Vanmechelen, Belgium, thought-to-be-a-rather-experienced-Access-developer

Reply | Quote

Replies

I have no experience running Access over a Unix network, but I don’t think I’ve ever heard of all the troubles you’ve been having in any network situation. Have you tried using Jetcomp to repair the databases? It often can fix things that the internal repair can’t.

Are these databases split, with a frontend and backend? And if so, is the frontend on the server or on each local workstation?

Reply | Quote

Mark,
thanks for your reply.

=> I don’t know Jetcomp but I’ll sure check it out (enough search engines to show me the way).
=> The database wasn’t split (yet), as I thought it wouldn’t be necessary with its small complexity & amount of users (1 to occasionally 5). In case you’ld propose it as a solution: as I now even started getting problems with linked tables, I’m not sure it will help, but I’ll try it out…
=> More in my answer to Douglas Martin…

Reply | Quote

Jetcomp is available from Microsoft site.

As for splitting databases, it has nothing to do with size, complexity, or # of users; I routinely split all my databases, especially those being used by others (be it one person or a bunch). For one thing, they are easier to maintain; I can modify the frontend, test it, and then distribute it all without touching the backend data. Split backend databases are also less prone to corruption, and lost data. In a network environment, you put the frontend on each workstation, which improves Access performance, and decreases network overhead.

Of course, this has nothing to do with your problem. I’d start suspecting the network itself.

Reply | Quote

Haven’t seen the problem about restricted access to queries and tables. I have seen the other two. Yes, if your database gets corrupt, autonumbers can “forget” where they were. Rather than do what you did, when I had that happen to me I tried a compact; that did get the autonumbers back where they should have been. However, it didn’t take long after that happened to me before I realized that the database was corrupt in other ways.

One hint with Access 97 (Access 2000 automatically enforces this) – do not make any changes to the definitions of forms or reports when anyone else is in the database. If your database is split into front-end and back-end, the rule only applies to people using the same front-end that you want to change. It doesn’t matter whether anyone else is using the same form or report that you want to change; simply the fact that they are in the database seems to make Access 97 very wobbly.

Reply | Quote

Hey, Douglas,

So at least some of the mystery can be solved…
Thanks a lot about the hint about NOT designing while other user(s) is in the database. From this point of view, even for the smallest database, splitting it in front and back end ends up to be a good idea anyhow… And putting front ends on each work station, even with this tiny app, is, knowing this, worth a consideration as well.

Further, I’ll try to figure out if designing & developing the databases on my pc hard disk ( network) might enhance stability.

Right now, I wonder if there is an alternative to the worst case scenario: recovering an old old backup from before we started using it with more than one person, import the data from the latest version and restore the (fortunately – hopefully – limited) design changes made since then. Any suggestions?

Thanks a lot for the advice, and (?) the shared experience of Access 97 going ‘wobbly’!

Hans

Reply | Quote

Hans,

There is an utility at FMS Inc Total Access Detective that compare two databases and generate reports with the difference between the two. If you want to use it only once it’s expensive, so if you send me the two database I can compare it for you and send the reports with the design changes. See my e-mail address in my profile.

Reply | Quote

Hans,

I’d like to add my to the excellent suggestions others have already given.

I had this problem of database corruption in a multi-user environment in Access 97. As far as I have been able to trace it, it happened as follows:

1. User A and user B both open the same form.
2. User A sets a filter (or changes the sort order, or …).
3. User A closes the form. Access sees the filter (or sort order or whatever) as a change in the design of the form. It tries so save the form (without asking for confirmation). But since user B also has the form open, there is a conflict. Apparently, Access can’t resolve this gracefully.

This problem doesn’t occur if you make the database into an .mde database, or if you apply database security, so that standard users can’t modify the design of forms. (There are other forms of corruption of course. Memo fields seem to be prone to corruption, and Access 97 is extremely sensitive to network problems)

If .mde or database security are not an option, you might try the following:

• Set the border style of forms to Dialog, so that they can’t be maximized.
• Try to prevent users from inadvertently saving a form, by not showing the standard menus and toolbars.
• Prevent users from closing a form except by using a “Close” command button. I use a Boolean variable for this (see post 166577 – it has an attached example of this).
• Close forms in code without saving them:
  DoCmd.Close acForm, Me.Name, acSaveNo
  [/list]I have used this method in a few databases where .mde or database security were not possible (for reasons I won’t go into here). This has eliminated the corruption problem almost completely .

  Regards,
  (another) Hans

Reply | Quote

Thanks HansV,
there were still several pieces of valuable information in your reply which I didn’t know about…

I’ll try out the mde-solution and wait and see how far it’ll bring us. The rest, I’ll surely keep in mind.

((Meanwhile, I’ve built the file up again by (0) starting a new file (1) importing the actual tables from the corrupt one (compact) (2) importing the forms from an old backup which should be ‘clean’ enough (compact) (3) recreating the queries by copying (only) the SQL in design view from the original queries in the corrupt mdb (these couldn’t be opened in design view no more, but after importing them in another mdb, they did…) (compact) (4) splitting => backend+frontend (5) frontend => mde (6) copy mde => workstations. ))

ps just fyi…

About preventing a user to close a form by other means than the close-button…
I checked your post & it worked fine. Though, maybe also this variant, which I once used in one of my (few) app’s, is worth mentioning:
Private Sub Form_Close()
cmdClose_Click
End Sub
Advantage: you don’t need the variable & the user saves time: his first trial to ‘get out’ will work. And no matter how the form is closed, it’s closed as if the close button was used.
Disadvantage: I hope I didn’t overlook any possibilities…

Reply | Quote

Hans,

Thanks for the tip. It looks good. I’ll be sure to try it.

Regards,
HansV

Reply | Quote

Hans,

You suggested[indent]

---

Private Sub Form_Close()
cmdClose_Click
End Sub

---

[/indent]It looked promising, but when I tried it, I found a couple of problems:

1. Error 2501 (action canceled) occurs when you close the form. You can get around this with an error handler that ignores error 2501.
2. When you click the Close command button, the OnClick routine is run twice: first because you click the button, then again from the OnClose event. If the OnClick routine contains more than just the DoCmd.Close, this is annoying. You can get around it by creating a Boolean variable and setting it to True the first time, and exiting immediately if it is True. But your suggestion was meant to avoid the use of a Boolean variable…

Still, it was worth trying.

Regards,
HansV

Reply | Quote

Well, Hans,

so my solution was too simple to be true…
I assume I indeed didn’t get these problems because no extra code was included for the close-button. Mea culpa.

Adn thanks again for giving your comments, also on this one – so at least no-one will use it without being warned about the consequences.

Hans

Reply | Quote

Hey, Hans (and eventual other valuable members of this lounge)
some time has passed since this thread was written and practicing your advice, in none of my databases here (maybe because multi user use was very rare), corruption has occurred ever since. Now, however, it’s getting serious and I’ll want to provide some database(s) for a couple of users. So… some additional questions…

Given an mde frontend and a backend, both Access 97, with max. 2-6 simultaneous users.

1. Are there additional advantages to put an mde copy on each user’s desktop? The only one I can think of are network traffic (?) and the fact that you allow each of them to gather their own set of custom queries.
(BTW: the latter seems to create the complication that each time you come up with a new version, you have to transfer those custom queries to the new copy…)

2. Do I risk more corruption when using no record locking?
I choose this strategy as we will probably never (… say never …) work in the same records and because literature tells that this would probably lock several records at a time… which would probably provide more frustration than it would solve :-).

3. Is it still usefull compacting the frontend on a regular basis? (It seems to me that compacting the backend remains as important…)

(4. This goes to a new thread: workaround for corruption prone memo fields)

Reply | Quote

1. In general, it is recommended to give each user his/her own copy of the front end database. Less chance of form corruption. This should be less important for mde databases than for mdb databases, but still…

2. I don’t think so. I don’t set record locking in my databases and have no problems.

3. Yes, even frontend databases increase in size.

Reply | Quote

Thanks!

Reply | Quote

Thanks!

Reply | Quote

(Edited by hasse on 22-Apr-05 19:02. Update 22/4)

Progress report… (to keep you informed about whether the project eventually succeeded)

22/03/05 : start testing the new database. Corruption risks should be acceptible (low) as I respected the instructions above (2). Security isn’t an issue at this moment (lucky me). Users are happy & me too (1).
Still, any more suggestions about things to take care off when multiple users are concerned, are still welcome…

15/04/2005: database still going well (several related tables with up till now +- 1000 records). Max number of simultaneous users: 4. Two issues:
– (first) sometimes users got false duplicate key error messages.
Solution: quit record & start again;
– (then) I got false 3112 error while (and so prohibiting) compacting the backend: “Record(s) can’t be read, no read permissions on ‘PathFile.mdb'”.
(Used) solution: Access Maintainer. (Thanks Abraxus for referred to it in Re: Can’t Compact (97SR2) (Access 97/SR2).)
Maybe I should look for a more advanced backup strategy which allows to compare both databases & search for suspicious data differences between both (indicating corruption).

22/04/2005: other users satisfied & me too. Being able to build reports on the fly is so much fun . Same issue though:
– at compacting using regular Access compact & repair (which I admit was done only at the end of the week). This time also Access Maintainer raises type mismatch error and auto generated error tabel points at duplicate key in a table.
Solution: Indeed, one record appears twice, with identical primary key and automatic user & time stamp fields. Weird. Deleted the record. Compact & repair & … OK! BTW: Access Maintainer keeps raising the error untill I delete & re-enter the search path before running it. I’ll report it to the developer if it re-occurs. Will check out Wendell’s suggestions below.

(1) I’m really sticking my neck out here. After the prior bad experience (cf. start thread) my boss still wasn’t fond of using Access with several people at once. Further Access (here) has a bad name all over the place: one of our administrations’ IT dep has even dropped Access support, our IT dep generally advises to avoid Access and also the IT’ers around here will probably rather laugh and say ‘see I told you’ if anything goes wrong,… So I’m holding my breath… On the other hand, I realize (or at least strongly hope) that many problems are due to a lack of knowledge. For example, probably almost nobody here (among thousands) work with split databases and a front end mde copy for each user. So… if this turns out to be a success… there’s some news/tips that might be worth spreading around .

Reply | Quote

It sounds like you actually have a fairly stable situation, but you might want to look as MSKB HOW TO: Keep a Jet 3.x Database in Top Working Condition – it has numerous recommendations for keeping an Access 97 database tuned up. In my experience, you might also want to consider moving to at least Access 2000, as Jet 4.0 continues to get maintenance and in my view is more stable than 3.x. In addition, you are likely to see issues with someone who gets a new workstation with Office 200x, and tries to open your database. Even if you create a unique front-end and link to the 97 back-end, you are like to see performance problems and eventually corruption. Another thing you might take a look at is SQL Server (or even mySQL) as a back-end. Those kind of products tend to be more stable in the long run, especially if you have occasional network problems.

Reply | Quote

Progress report… PROBLEMS…

We are up to max 4-5 users at this moment…mostly using one data entry form with a subform and two synchronised (sub)subforms (*)
Today problems have been adding up… hope we make it till the upgrade to XP in a few months:
(- duplicate key value error: can be explained and solved – OK;)
(- unrecognised database format: once);
– entered record duplicates for no reason. Removing one ‘twin’ makes also the other disappear (values change in #DELETED – record remains present also after closing and reopening form);
– invalid bookmark;
– previously entered records in main table disappear… while ‘sub’records in related table continue to exist;
– other data entry loss in main & subforms: this seems to become main problem.

Trial solution: backend repair
– repair, compact
– copy database to hard disk; import all it’s tables in new database, compact new database; replace original backend on the network by this new copy.

The input lost (see above) is partly restored (after apparently having been in some no mans land) and at first sight, it looks OK. But…
Problems start to reappear. There are two active users. Where problems first happened more with one particular user (also after I gave her a new copy of the frontend), they now seem to start affecting the other too:
– again data entry loss in main & subform
– when a user leaves a subform (by clicking another tab on the form), entered values in all subform records turn into #ERROR. Only the last record shows… a value which just has been entered by the other user for another (main form record) file.

MAYDAY. Any immediate suggestions?
(will try and have a further look around the net & forum tomorrow too)

@Wendell: all users have SP2 installed… so I expect all have the latest Jet version… but for certainty’s sake I I have contacted our IT helpdesk to check if all users’ Jet version is the most recent one…

Hasse

(*) Access 2002 Developer’s Handbook p. 502 e.v. “Using Synchronised forms”

Reply | Quote

Are you certain that all of your users are running Access 97? This sounds suspiciously like the corruption issues that I’ve seen with an Access 200X front-end working on an Access 97 backend. It might also be possible that a workstation has both 97 and some version of 2000 installed. Finally, using synchronized sub-subforms in Access 97 could be at the root of your problems with data entry – especially if you are using code from Access 2002 VBA. That’s about all I can think of at the moment.

Reply | Quote

Wendell,
thanks for your reply. I could repair the database with jetcomp.exe, importing the back-end tables into a new file, repair-compact again and redistribute the front-end to the users. Little data was lost but problems seemed to be solved.
There’s a slight chance that XP-users might be a reason (*)… not the use of Access 2002 VBA (**). Now I wonder:

1. I remember that up to 5 users should be no problem… but does this also refer to simultaneous use? Or… could 3-4 simultaneous users be too much for Access to handle? Looking backwards, last time, it seems like the problems (cf. previous post) started after a third/fourth user started data entry for a while. Ater recovery data entry restarted with two active users with no problem for 2 days. Right now, after a third user entered the arena, a new problem occurred ((temporarily?) solved with repairing & compacting the back-end) (****). Makes me wonder whether this is coincidence or not…

2. Do you have any suggestions about services/software that scan a database for eventual corruption issues, providing some kind of diagnosis? I found (plenty of) deals with database recovery… but no diagnose (***). I consider contacting these webservice & software suppliers with the same question… but if you have a clear suggestion, this might save me the effort…

(3. Probably more hard to answer: I can clean front- and back-end by importing all objects in new databases, run jetcomp.exe and “Access Maintainer” on them, repair & compact… create a new mde and redistribute it to all users. Is there much more or else one can do? And… is this (or certain steps) useless after a successful repair & compact of both front- and backend?)

Hasse

(*) Some background info: there are (almost) only 97-users… but we have three XP-users whom I ordered not to use the 97 database and afaik they didn’t…
One pretty stubborn one might still have tried in the past… but that should have happened long before the problems started. She is now also on holiday for two weeks and I have no access to her pc.
At a second user, I tried to create a XP front-end but she apparently has indeed 97 and XP on her pc. When I opened a 97 front end (don’t remember if it were an mde or the original mdb in order to convert it to XP), it opened without any warning or option to choose conversion/read only… I placed a 97 copy on her desktop but she confirmed not have used it since.
A third XP user sure has not 97 and XP installed. She works now at another collegue’s WinNT- Office 97 pc, where our IT-dep created a new ‘NT-profile’ (after an earlier attempt to let her use it under her normal XP-profile failed: Access – in general, not just this db – raised start up errors and couldn’t be opened).
Btw… XP has only be used to (try :-p) create an XP-frontend for these XP users… but for reading data only. I asked not to use it for data edit/entry and I believe this has been respected. Although… maybe ‘looking at’ already is enough to cause problems…
It’s pretty a mess here which hopefully can be solved with an overall migration to XP in a few months.

(**) The database is entirely developed in 97.

(***) E.g. good info page at http://www.vb123.com[/url%5D.

(****) Current problem (solved):
– error: user gets key duplicate error for no good reason: table checked, no duplicate found;
– compact & repair: while compacting the backend after all users quit database, I get a warning I don’t have access to all records. Problem solved with database repair: after repair, I can compact with no error;
– user problem solved: data can be entered now without error.

Reply | Quote

If there is any doubt about one of your users using XP to open the database, I would look there first. For one thing, even if your front-end is a 97 MDE, you are still using the Jet 4.0 engine in an emulation mode, and it does things differently when it comes to adding records where an autonumber is the primary key. Also, in some of the service packs for Jet 4.0 there apparently was a bug introduced that caused some problems with autonumbers – as far as I know it is resolved in the most recent version. In response to your questions:

1. Normally 5 users should not be a problem – even with 10 it should be OK unless they are all doing heads down data entry. But I should add that the design of the database can contribute to it – if you adding numerous records in code based on data entered into a form you are adding the equivalent of several more users. If you are doing that sort of thing, you should probably look at a true database engine such as SQL Server, Oracle or mySQL.
2. I don’t know of any database vendor that offers corruption detection and evaluation tools for either Jet 3.x or Jet 4.0 databases.
3. If you can successfully repair and compact the database, that should be sufficient. If you cannot, then you should resort to copying to a clean front and back end.

Reply | Quote

Wendell,
thanks for your informative answer. The issues you mention should be ok now:
– there are no more XP-users since last reparation.
– no records are added in code: the synchronised subforms use only (i) one line of code in the ‘primary’ subform’s current & update event to update an unbound textbox with the current ID “Me.Parent(“utxtPo_ID”) = Me!po_ID”… and (ii) a reference to the same textbox in the ‘secondary’ subforms LinkMasterFields;
– the (max 3-4) Access 97-users do no heads down entry… but in the subforms data can be entered pretty fast (with irregular peaks of a few records per second) – that’s the only problem I can think of.
As to this morning, again, a subform record entered by one user appeared shortly in another user’s window. Problem ‘solved’ by going back and forth in the main form’s records… which made it disappear. Still I decided to do one more compact using jetcomp.exe on both backend and mde-front-end (which I redistributed).

Situation is now moreless under control – I think I’ll have to live with it… and daily compact & repair the backend.

Further… to all professional developers… apparantly there’s still a hole in the market for a corruption detection and evaluation tool .

Thanks for your time – and hopefully this is my last post here
Hasse

Reply | Quote

Fwiw…
– I might have found another cause of corruption: (Preventing) corruption due to no disk space (97+);
– an upgrade to an informix back end might not solve much issues when we connect to it through the same network – cosidering Charlotte’s reply in the Access Stability (XP) topic (which adds to HansV’s earlier comments):
[indent]

---

Access is extremely sensitive to network interruptions, far more so than any of the other Office apps. In fact, it acts as a sort of “miner’s canary” for network problems. Network administrators customarily blame Access for these problems, but they really indicate a situation that needs to be looked at more closely. Things like a single chattering network card on a LAN can bring Access down intermittently. That isn’t a problem with Access, it’s a network issue, but it is far easier to blame Access than to track down the wiring or other hardware problems that exist but don’t seriously affect other applications.

Moving the whole thing to SQL Server requires a database administrator and someone to convert the application and create a new front end. If the backend is SQL Server and you link the tables to an Access mdb front end, you don’t gain any more network stability because Access will not tolerate network interruptions, regardless of the back end, and will not “repair” itself when the connection is reestablished. Your one person with full Access should be using the runtime as well. There is probably a difference between the versions of the files she is using and those installed with the runtime. That will definitely lead to the kind of crashes you describe. That person can use a shortcut that includes the runtime executable to run the application without changing their ability to use the full version of Access for other things.

Charlotte
Moderator: Access, VB/VBA, Books, General Office Solutions

---

[/indent]
– we are considering using Access through Citrix… but this would require a license for every user… (600

Reply | Quote

FYI… at some point… even after a migration to the Access 2000 format, we could not access our database with multiple users anymore.
Our IT helpdesk came with a double solution:
– install jet35sp3.exe
(this might have caused at least part of the problems we were having when using the Access 97 format – makes me feel pretty stupid as I thought I had checked that)
– network drive NFS properties ‘File locking’ and ‘File sharing’ must be set OFF (*).
(which seems to have been crucial, also in higher version(s) of Access)
Now we can access the database again with multiple users at once… probably thanks to the latter.
One user already let me know that the database is faster now too.

So… apparently the system which makes our Windows communicate with the UNIX network prooved quite important.
I’m not an expert, but I found a substantial article here discussing issues with SAMBA file locking/sharing which seem very similar to what I had to cope with here.
This might (!) be applicable to NFS too (but I might be mixing up things here).
(Just) some excerpts:
[indent]

---

UNIX or NFS Client-Accessed Files

Local UNIX and NFS clients access files without a mandatory file-locking mechanism. Thus, these client platforms are incapable of initiating an oplock break request from the server to a Windows client that has a file cached. Local UNIX or NFS file access can therefore write to a file that has been cached by a Windows client, which exposes the file to likely data corruption.

---

[/indent] [indent]

---

Multiuser Databases

Multiuser databases clearly pose a risk due to their very nature they are typically heavily accessed by numerous users at random intervals. Placing a multiuser database on a share with oplocks enabled will likely result in a locking management bottleneck on the Samba server. Whether the database application is developed in-house or a commercially available product, ensure that the share has oplocks disabled.

---

[/indent]
I hope this makes sense… and could provide some solution to others as well…
Take care,
Hasse

Reply | Quote

Final solution proposed by our (outsourced) IT helpdesk:move the database to a Windows server… (which’ll get it’s own mapping in our users’ windows explorer).

FYI
– remaining problems: we didn’t experience any corruption (yet), but still could not access the database with multiple users (except, apparently, the first time we tried… but that’s typical I guess?). It seemed like the *.ldb file still doens’t always disappear after the last user has ‘left the building’,…
– their explanation: the software which facilitates the link/correspondence between the unix server and windows workstations (Samba, Reflexion,…) always has it’s imperfections… and in our case (Reflexion) it ‘s apparently causing you can’t access the database with multiple users and a increased corruption risk.

Reply | Quote

1. In general, it is recommended to give each user his/her own copy of the front end database. Less chance of form corruption. This should be less important for mde databases than for mdb databases, but still…

2. I don’t think so. I don’t set record locking in my databases and have no problems.

3. Yes, even frontend databases increase in size.

Reply | Quote

Hey, Hans (and eventual other valuable members of this lounge)
some time has passed since this thread was written and practicing your advice, in none of my databases here (maybe because multi user use was very rare), corruption has occurred ever since. Now, however, it’s getting serious and I’ll want to provide some database(s) for a couple of users. So… some additional questions…

Given an mde frontend and a backend, both Access 97, with max. 2-6 simultaneous users.

1. Are there additional advantages to put an mde copy on each user’s desktop? The only one I can think of are network traffic (?) and the fact that you allow each of them to gather their own set of custom queries.
(BTW: the latter seems to create the complication that each time you come up with a new version, you have to transfer those custom queries to the new copy…)

2. Do I risk more corruption when using no record locking?
I choose this strategy as we will probably never (… say never …) work in the same records and because literature tells that this would probably lock several records at a time… which would probably provide more frustration than it would solve :-).

3. Is it still usefull compacting the frontend on a regular basis? (It seems to me that compacting the backend remains as important…)

(4. This goes to a new thread: workaround for corruption prone memo fields)

Reply | Quote

SOLVED! (Thought I should let you know )
Meaning…
Since we migrated from our Unix server to a Windows server, we can ‘multi user’ access the database without any problems so far (at this moment, for example, with 4-5 users simultaneously).
Take care
Hasse

Reply | Quote