Hi, we are having a recurrent problem with a navision 3.60 database. From time to time this message is given by the database server: “This function cannot be executed while the database is being used by other users.” This is the error 1055 in module 2 (or 19, depends on where you look at). In the error list floating around this text is also given: “Err_DB_MoreThanOneStation” Then we have to restart the service and everything goes fine until it happens again. We have some tools written with the C/FRONT library that access that database, apart from some classical clients. If somebody have some information about what this error means, what is the cause and/or which are the possible solutions and could post it I would be very happy. If you need more information I would be very glad in posting it. Thank you very much. Regards, Tomeu.
How many connections (batabases) using cfront ? There are problem with cfront connection handling. Bad design of software.
This database has the following clients intermitently connected: - An ISAPI filter that looks up users in this database. - An NT service (A) that reads its configuration and writes a log. - Another NT service (B) reads data from this database and also from other two, the connections could be all open at the same time. - A CGI that reads data from some tables and ocasionally makes some changes on them. - A windows application that opens many connections to many different databases. - Some standard clients also access to this database. As you can see our organization is relying a lot on the C/FRONT, but with this problem we cannot offer any reliable solution based on C/FRONT. Do you know what this error means? Could be that the server enters in “one user mode” and gets locked for other clients? What causes this? Can be related to multiple instances of a DLL in a client machine? Thank you very much for your interest.
Such errors hapens then, you have one cfront dll directory, and run more than one instance of Cfront from the same firectory. Then cfront starts it creates semaphore, what have connection identification (I think that it have database/server and client ID’s). So then you try open another connection it checks - it is the same database or server. If it is the same - No errors, if different - ERROR. Another problem is that Cfront, don’t like multithreading. If entering to the same instance of cfront from differnt threads, it may couse a lot of errors. To avoid these kinds of error, use: 1. Create for each database directory of CFront dll files. 2. For each session use one instance of cfront. 3. Never pass one to other cfront instance rec or table buffers, pass only data. More suggestions: Better is to use dll (Loadlib function) than ocx. Rewrite navision distributed loadlib.c file to OOL style (define Cfront dll like class), it saves a lot of time. I’m not palyed with NA 3.6 version, but from NF 1.3 until NA 3.1 cfront was designed like “one user mode” and “one thread” dll. All may aplications full of mutexes and semaphores. I have impression that Navison programers don’t know waht is OOL and multithreading, I hope that Bill Gates teach them 
Hello again, thanks for the info, but we already had those issues into account. Another possibility occurs me: could that message mean that other process is using the fdb file? Perhaps the backup utility or a local client? Tomeu.
Yes, it could rise error, if running from the same place (directory).
I think we have found the cause. If one process executes DBL_ConnectServerAndOpenDatabase DBL_OpenCompany DBL_DisconnectServer DBL_ConnectServerAndOpenDatabase DBL_OpenCompany the second connect function gets executed too fast after the previous disconnect, causing a sharing violation (perhaps the finalization code hasn’t already released all the files) and ultimately raising this error. Just introducing a short delay seems to fix this problem. Does it make sense to you, Dalius?
You need also CloseCompany and ReleaseAllObjects. The problem was, that you making connection with old connection obj cache. ReleaseAllObjects instead delay, will fix problem too.