Data changing and reverting-MS Acess FrontEnd SQL Server BackEnd

swilsy

New member
Local time
Today, 11:24
Joined
Dec 29, 2013
Messages
4
I have come across a very frustrating and perplexing problem. I have been all over google, but have been unable to find anything about it.

System Specs:
I am running an Access .mdb front end with a SQL Server back end. The tables all have primary keys declared and foreign key relationships. The SQL Server tables are linked to the Access front end via ODBC. A single copy of the Access front end file is located in a shared network location and is accessed by multiple users at any given time. There are about 15 to 20 users that could have an instance of the Access front end file open on their machine at any given time. In the front end file there are a lot of queries, forms, and reports. All of the forms and reports have some amount of vba that go along with them. The SQL Server is the Express edition of 2008 R2. All of the users are running Office 2007.

Problem:
I spent a great deal of time updating data in our system about two years ago. Over the last couple of months users have been telling me that data is missing or incorrect when I know that it should be correct after my updates. Because I create backups for the SQL Server database periodically, I was able to look at older version of the database and discovered that the data had in fact been updated as I thought, but now those line of data are missing or incorrect. I am the only person who knows how to update data en masse, and no one would go in and intentionally alter this data. It is widespread enough, that I know it is not the result of an accidental keystroke.

The front end does have some built in features that are used for copying data which I did not create. (In fact I inherited this whole system, and have just made additions and modifications here and there) We are a manufacturing firm that creates custom versions of our standard products, so bills of materials often need to be copied, then modified for the custom version. Yesterday I executed such as copy with the front end's tool and ended up with a crazy result. When I copied the bill of materials from the original, it copied an old version of the original product's bill of materials into the custom version's bill. It was insane. I double checked the bom of the original and it was the up to date version, but somehow the old version of the bom ended up copying into the custom product's bom. The only thing I can think of, is that somehow the old data has managed to store itself (from as long as two years ago) in the Access front end, and somehow that data was pulled from by the vba that executes the bom copy function.
Has anyone seen something like this before?
 
Start by giving each user a separate copy of the front end.

Temporary tables related to the copying of the BOM are probably being stored in the Front end and this is where the old data came from.
 
Is there a way to be sure that temp tables are cleared? I am able to kick everyone off of the front end to gain exclusive access. If I give everyone there own local copy, won't the local copies potentially have old stored data in them as well? Also, won't each user potentially have different temp tables with their own copies of the front end?
 
Is there a way to be sure that temp tables are cleared?

Find them and clear out the data. They my be hidden from the Nav Pane.

Normally a delete query is run immediately prior to the temporary data being loaded so it should not normally be a problem unless there is something wrong with the code.

However some developers turn off warnings before running a query with DoCmd.RunSQL. This technique allows all errors to be quietly ignored too. Perhaps that is happening. Better to use CurrentDb.Execute to run queries and include dbFailOnError as the second argument so real errors are raised when there is a problem.

Also, won't each user potentially have different temp tables with their own copies of the front end?

That is typically one good reason to ensure that users do have separate front ends.

With Temp tables in a shared front end two users could end up with their processing overlapped causing complete chaos.

BTW The use of Temporary tables inside the front end is a very common bad practice indulged in by even seasoned developers. I am an advocate for using a completely separate disposable local database where temporary tables are required.
 
I'm sorry I thought you were referring to automatically generated system temp tables (which i knew nothing about). To be clear you are referring to temporary tables used for completing operations by the developer which sits in the front end?
 
I'm sorry I thought you were referring to automatically generated system temp tables (which i knew nothing about).

SQL Server can have temporary tables managed by the engine but Access doesn't support them natively.

To be clear you are referring to temporary tables used for completing operations by the developer which sits in the front end?

Yes.
 

Users who are viewing this thread

Back
Top Bottom