Run-time error 3044
-
Multiple users were in my database, which is a FE/BE split MDB.
Has anyone experienced errors like this:
"Run-time error '3044':
(Location of the BE database on the network) is not a valid path. Make sure that the path name is spelled correctly and that you are connected to the server on which the file resides."
This error is a Microsoft Visual Basic message box with standard continue/end/debug option.
There was also a message box saying:
"Disk or network error."
Is this file corruption?
Sometimes the user is still connected to the network. Sometimes the user is not connected to the network anymore. Also, this seems to occur to a few people at a time. Just a few though. Two or three people who are in the database will have this message pop up and the rest of the users who are logged into the database experience no problems. What is going on here?
-
Also, will moving to a MDB FE linked to a SQL Server 2000 BE through ODBC greatly reduce the chance for database corruption?
-
When you use splitted Access DB every time you change the BE path you need to use the "Linked tables manager" to refresh the location of it ( or do it through code)
moving mdb file to SQL BE is not just to use a different BE you will probably need to change the way you code things ( and probably a lot
)
* Noel -
I know about linked tables. I didn't move the location of the BE. The application dropped connectivity to the network while users were using it, for no apparent reason. That's why I wonder if the file was corrupted due to the poor performance of Jet as a database engine.
-
Your users do not have the same share linked to the same path. If the FE is set up to find the BE at J:\MyDB\GoodStuff.mdb, then all users have to have drive J mapped to the same share. This is an issue with Access. You cannot use UNC names, it's gotta be mapped, which also means you gotta be logged in in order to do any processing, no services doing stuff when you are logged out.
Access if a fantastic application, considering it is designed as a PERSONAL data base, but because it is a personal DB, it has it's limitations.
Shalom!,Michael Lee
-
Actually you can use a UNC name to link a FE access mdb to a BE access mdb. I do this a lot. Is the FE mdb file installed on each client or is everyone using one FE mdb file on the network? I've had better success having the FE mdb installed locally on each client and one BE mdb in a common network folder. If everyone is using the same FE mdb file on the network that may be what is causing the problem when you get too many people trying to use it at the same time. That could cause corruption on the FE mdb file.
-
I began by using one shared FE mdb but switched to a locally installed FE mdb setup a while ago after reading other recommendations. I just want to know whether there are significant advantages (other than back up and recovery) to using SQL server as the BE through ODBC linked tables.
-
I support an application that is a FE mdb linked to SQL Server through ODBC and currently we have anywhere from 150 to 200 concurrent users. We are starting to hit a threshold limit on this and are considering replacing the FE with a .Net application. But we have operated just fine with this setup for the past 5 years. My recommendation would be that if you are going to have to do substantial rewrite to use linked ODBC tables and you have the resouces to rewrite the FE in something other than Access to do that. However, if it is a choice between Access using an Access database and Access using SQL Server, you will probably see improvement using SQL Server.
-
Interesting about the ability to use UNC. I even created an incident with MS on that one, and was told no way. Of course, this was with Access 97. I think there are a few changes between 97 and 2003
We run ~40 - 50 users on a shared server based FE to SQL Server BE. Never had any multiuser issues. The advantages are I know all my users are running the same version of the FE.
As far a performance, 97 using linked tables to SQL Server blows away the competition with speed. 2000 and 2003 using linked tables are snails, and 2003 as a Project file can hold it's own. Access Project returned so much of a better performance, that we migrated to it. The trouble with migrating to a Project file is every SQL command must be re-written in the SQL Server dialect, rather than the Access dialect, and there are a lot of differences.
Shalom!,Michael Lee
-
I have a lot of form referenced action queries in my FE MDB, so moving to an Access Project FE would be an enormous amount of work. I doubt the benefits will be worth the work.
I am operating on Access 2000. Is Access 97 really much faster than Access 2000 and 2003? Why do you think that is? If you design the FE application correctly, shouldn't the different versions run at about the same speed? How much faster/slower are we talking about, and what is faster/slower? Queries, forms, reports?
What do you mean by starting to hit a threshold limit? Based on Microsoft's number of 256 users? It is very reassuring to hear that you haven't had any problems for five years using the Access FE SQL BE setup with 150-200 concurrent users. Are you using Access 2000? Have you had any performance/speed issues? The conversion from an Access BE to a SQL server BE will be pretty painless for me. It will not require much rewrite of the FE. I have to move the Switchboard table to the FE instead of linking it in the BE and I had to rename a few fields, but that's about it. I could eventually move a few queries to the SQL server and link them. That should increase some speed, right?
-
-
Sorry, things got busy around here. By threshold limit I mean that we are now starting to see performance and speed issues, problems with memory resources on the server, queries taking too long to execute and locks being held too long. I think most of the problems we are having are due to the design of the FE application where most forms have at least 2 combo boxes that populate with all the records from a large table, (one allows selection by id number, one allows selection by person's name). As the size of the table continues to grow, performance is getting worse. It's more an issue of a poor FE design than the fact that it is an Access FE linked to SQL Server.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply