This question already has answers here:
Recent rash of Microsoft Access database files in an inconsistent state
(2 answers)
Closed 2 years ago.
We have a client that uses our MS Acccess based software, they are up to
20 users working on the front end at the same time.
Each user has its own .mde front end and the backend database is a .accdb...
My question is why only this clients database keeps getting corrupted or in an "inconsistent state". None of our other clients expierence this problem.
Any tips or advice?
This is now a "known issue", documented in the Microsoft Support article
Access reports that databases are in an 'inconsistent state'
The article currently includes a workaround involving configuration changes on the file server. It also says that they
are testing a fix for this problem now, and will give further updates when we can confirm that this resolves the issue
Related articles (e.g., here and here) suggest that the errors are a combination of
a new File Sharing (SMB) feature, "Leasing", introduced in recent versions of Windows Server, and
removal of an older SMB protocol from Windows 10
Depending on the version of the OS and the version of Access being used the mde file may not run properly. If they have a 64-bit version of access, and the mde was compiled in a 32-bit version, it may not be recognized correctly, but a accdb file would work fine, and you could lock it out as well.
Also, if your using an accdb back end, and need to use a compiled front-end, switch to using accde front-ends instead, as those are the modern compiled versions and mde should only be used in versions of Access prior to 2007.
My only question for you is to find out if the users are running from a network location or a local folder - as running any Access DB front-end from a network location can cause issues. Have the accde file (or the front end) copied to their desktop first, then run from there.
Also, after download, you can run a file size verification to confirm the whole file was downloaded, as I have seen wifi connections lose part of the file during download, and then that causes corruption too. If possible, split the interface into multiple, smaller files, to make the download more reliable.
It is also possible that this 1 client uses your app differently than you expect. Users are after all the ultimate debuggers.
Any table that has a primary key that is not an autonumber - is a candidate to be the cause in a multi user application should it be possible that multiple persons initiate a new record without entering the primary key value immediately....or even a single user that initiates a new record but does not complete the act entirely and leaves the PK field blank.
Other: although one can copy a back end file during use without affecting it - there may be some well-intended server functions that auto duplicate/copy/exchange files that may be the cause.
This completely solved the issue for me (with Windows 10, 1709):
I replaced all ACCDB back-end files with MDB back-end files. I am using ACCDB front-end files with MDB back-end files. I have a password set on the back-end files but I do not enable file encryption. No corruption since then!
To do this, simply create a new MDB file and transfer your back-end objects to this new file. I did not implement the Microsoft workaround (disabling leasing).
Alternatively: replacing any DoCmd.RunSQL command with DoCmd.OpenQuery (and a query object) reduced the occurrence of corruption by about 80%.
Related
Guys I'm working on a local system project where I'd use Microsoft access as the database storage.
This application may be distributed among several users with different access layer control.
The direct method to secure the database from manual update is to put a password lock, however I came across this software today: https://www.accessrecoverytool.com/how_to_recover_access_password.html
It simply cracked my password with special character instantly.
May I know if there's any better way to secure a ms access mdb file?
Thank you.
there are many considerations when it comes to security. as E.v.A. has already posted, at a minimum, don't use the old .mdb file format and instead use .accdb or .accde (to compile the front) or.accdr (user only has runtime version).
whether or not the password method for the .accdb has also been publicly cracked I cannot say as I do not monitor such things. Assuming it is the data you are concerned about (rather than the front end code) - then the accdb can encrypt the data so that one must have a front end, with the embedded pw in order to see the data.
One can always put the back end data onto SQL Server Express to then rely upon the SQL Server's security feature set.
Apologies in advance if this is a dumb question, but with Google's release of "File Stream", does anyone know how this would impact MS Access dbs stored on it?
My "setup" is that I have users that are routinely using an AccessDB that was built for them years ago, and I'm trying to replicate it in MS SQL. Not by my choice, the file is stored by the clients on a Google Drive: Which essentially means that I can only look at the vba and do testing when the clients are not using it. The clients also use Google's sync to access the file.
So my question is two-fold. First, if the clients are looking to move to File Stream and asked how this would impact their ability to use the Access file (I have no idea). Second, will File Stream make it possible to have multiple users on a MS database without causing conflicts or problems? Would I still need to make sure that I have exclusive access to the file while making changes to the vba code?
Thanks in advance!
UPDATE: Over 1k visitors with the same question and updating the description as asked by the person who marked this as -1 (now marked -2 without feedback) but the only question answered is that having multiple users simultaneously isn't sound. What remains is why a single user scenario can cause corruption of the file stored on stream: Compact/repair fails at least when the file is large.
Based on experience, you need to make sure only one person has the database open at a time. If two people open the database, then changes will not be saved. Try to find a different solution if possible.
The MSAccess database engine is fundamentally based on the database primitives provided by the MS file system. Including the record read/write/lock primitives. (Bet you didn't even know that MS operating systems had a native database system!).
Access records and tables are NOT filesystem records and tables, BUT -- the Access database system of records and tables are built on top of the native system of record locking. (The native system doesn't, and never had, any thing smaller than file-level authentication and permissions, so Access built a whole new system on top).
That means that any file system, or any network file system redirector, which doesn't support record locking like the MS file system and the SMB protocol, can't support simultanous multi-user access to an Access database.
I'm not familiar with Google FileStream, but I assume that it's a way to access binary objects using a database API? Normally that means the API doesn't look inside the binary object: so it can't be locking individual sections of the file for R or W or RW: that means you can't R part of the object while somebody else W a different part: that means you can't share access. ... and even if File Stream means something different to Google, the chance that they support SMB inside it is slim to none, right?
Can anyone confirm whether linking to tables in a Microsoft Access .accdr files is possible?
I have a split MS-ACCESS application with the frontend in a .accdr file and the tables in an .accdb file backend on a server. For reasons that I explain below, I need the frontend to connect to a table in a second backend file (also on the server) that has an .accdr extension.
I found no documentation that explicitly states that .accdr files are not allowed as as a backend database, however, the linked table manager does not seem to allow it, and the DoCmd.DatabaseTransfer method throws an error.
My workaround is to temporarily rename the .accdr server file as an .accdb, link to the tables in it to make the data changes, then rename it back to .accdr. But if I don't HAVE to do this, I would prefer to connect directly.
Reason:
To make sure that each client gets the most recently updated copy of the frontend .accdr, I created a batch script that first copies the frontend from the server to their local machine before launch. It's a short time penalty (the frontend is about 8 MB) each time they load the application, but the batch script makes sure that the client is ALWAYS up to date. (If performance became an issue I would of course have the batch script verify MD5 sums before downloading, but it hasn't come up yet.)
I don't have many clients connecting at the same time (only about 2 or 3 concurrent connections), but they can connect from any of thousands of computers on campus, so I found this the easiest way to make sure that no matter where they connect from, they will get a fresh copy of the FrontEnd.
Unfortunately, I made a few tables local to the frontend because they allow individual users to set parameters locally during a session. Now, of course, I have a case where an individual user needs to update these local tables so that all the other users will get this same data. (Previously, I had just been making these changes manually upon request, but this user quite reasonably needs to be able to do it herself.)
So, the local frontend .accdr file needs to connect to the server copy of the same frontend .accdr file to make a few data adjustments in a table. That's the reason. I know it's weird.
Thanks,
Damon
Turns out it is possible to use .accdr as a backend. I think i was specifying the wrong connection or something. I used this code snippet with the strConnect = path_to_mydb.accdr:
Public Sub ConnectOutput(dbsTemp As Database, _
strTable As String, strConnect As String, _
strSourceTable As String)
Dim tdfLinked As TableDef
' Create a new TableDef, set its Connect and
' SourceTableName properties based on the passed
' arguments, and append it to the TableDefs collection.
Set tdfLinked = dbsTemp.CreateTableDef(strTable)
tdfLinked.Connect = strConnect
tdfLinked.SourceTableName = strSourceTable
dbsTemp.TableDefs.Append tdfLinked
End Sub
You could easily add the tables that are local to your front-end to the backend. Just copy/paste them from one to the other, delete them from the front-end and link them to the backend version. Takes all of 5 minutes, no VBA code necessary.
Regarding the accdr as a backend question, then yes, accdr is meant to be a open by a the Runtime version of Access. Opening an .accdr file with the standard version of Access simulates the Runtime mode. The only difference between the standard version and the free Runtime version is that you can't access the design tools and the standard ribbon from a Runtime application (you need to create your own).
So renaming a accdb file into accdr only tells access to open the database in Runtime mode. It doesn't change the database itself at all.
So you can use an accdr file as a back-end without problem.
Pro tip: if you want your setup to scale a bit (easily up to 50 concurrent users) and have better performance, open a database to a dummy table from the front-end to the back-end. This will keep the connection open while the front-end is running and keep the lock file open on the database, resulting in better -and more reliable- performance.
I have a front-end Access 2007 apllication which talks to MySql server.
I want to have a feature where the application on the user's computer can detect that there is a new version on the network (which is not difficult) and download the latest version to the local drive and launch it.
Does anybody has any knowledge or exprience how this can be done?
Thanks
Do you actually need to find out if there is a newer version?
We have a similar setup as well, and we just copy the frontend and all related files every time someone starts the application.
Our users don't start Access or the frontend itself. They actually start a batch file which looks something like this:
#echo off
xcopy x:\soft\frontend.mde c:\app\ /Y
c:\app\frontend.mde
When we started writing our app, we thought about auto-updating as well and decided that just copying everything everytime is enough.
We have enough bandwidth, so the copying doesn't create any performance problems (with about 200 users).
Plus, it makes some things easier for me as a developer when I can be sure that each time the application is started, the frontend is overwritten anyway.
I don't have to care about auto-compacting the frontend when it's closed (and users complaining that closing the app takes too long...), and I don't have to deal with corrupted frontends after crashes.
#Lumis - concerning the custom icon:
Ok, maybe I should have made this more clear. There is only one batch file, and it's in the same network folder as the frontend.
The users just have links on their desktops which all point to the same batch file in the network folder.
This means that:
future changes to the batch file are easy, because it's only one single
file in one central place
we can change the icon, because
what the user sees is a normal Windows link
(By the way, we did not change the icon. Our app is for internal use only, and I'm working in a manufacturing company, which means that all but very few users are absolutely non-technical and couldn't care less about the icon, as long as it's the same on all machines and they know how it looks like so they can find it quickly on their desktop...)
Tony Toews has one: Access Auto FE Updater
It appears to be free, but I'm not 100% sure.
Lumis's option is solid, however if you want to check the version and only copy the database when their is a new version, have a 'Version' field in a back end table, and a 'Version' constant in a front end module. Keep these in sync with each new production release. Compare the table version against the version in the module when the main form of the front end database opens.
If they don't match, have the database close, but have the database call a batch file as the last bit of code to run as it's closing. The database should finish closing before the batch file begins it's copy process. If needed, place a minor delay in the batch file code just to be sure there are no file locking issues.
Would you recommend working with multiple programmers on an MS Access application?
One of our MS Access application has grown to the point where the number of changes (bug fixes) and new features can no longer be handled by one programmer in the requested time frame.
We are trying to introduce version control using the undocumented SaveAsText and LoadFromText procedures in VBA to make collaboration on this application possible. Unfortunately we have already run into problems loading modified forms and reports back into Access as a checksum is stored in every form text file.
Before putting time into building an import/export application to compile text files into an Access database, we would like to hear your recommendations.
I think you should avoid this path at all cost, and try and persuade management into redevelopment.
It's a bitter pill to swallow, but this is going to need to be redeveloped sooner or later, and you are just saving them time and money.
We were using Microsoft's own version control add-in for MS Access 2000/2002/2003 for about 5 years now, and I can't remember a single serious problem. Usability of this add-in barely deserves a "B", but it must be much, much more convenient than fiddling with any ad-hoc method involving manual or semi-manual exporting/importing of Access forms, modules, etc.
We were using VSS as a version control system all the time. No problems whatsoever. However, if you have some good reasons to avoid VSS, you may have some options:
The version control add-in that we were using does not require VSS. Theoretically it can be used with any version control system that implements Microsoft Source Code Control Interface (MSCCI). For example, when we had to let somebody work on this project remotely, we used SourceOffsite by SourceGear. Access version control add-in worked with this third-party product fairly well (not without some quirks, but well enough). So, if your favorite version control system complies with MSCCI, you could try to use it.
Now that Microsoft has this Team Foundation thingy, apparently there are other options to be used to integrate MS Access with version control. We did not explore this path, though. This article may be a good start for exploring it.
Hope this would be of some help. :-)
P.S. I am not a big fan of MS Access. In fact, I rather hate it as a platform for a user front-end. If I had a choice, I would run away from it yesterday. :-) However, I must admit that existence of this version control add-in is one of the few things that makes maintenance of our old Access+SQLServer project more or less tolerable. :-))
In addition to what I already said here, I should add that the whole system works very well. The comparison process takes less than 30 minutes a week, for a team of 3 programmers. So let's describe it a little bit.
We have basically 2 versions of our Access program:
The "Developer's version", with all the stuff in it.
We each begin to work with an identical version of our developer's edition. As each one modifies or add parts of the code, we have to run some comparison routine on a regular basis. To do so, we have an object-export routine to a common "comparison" folder. An object (module for example) is exported as a text file (saveAsText command, do not work with tables, see infra), it will be compared to the existing equivalent text files in the folder. If files are identical, there is no file exported. If files are different, the new module is exported with the developer's name as an addition to the file name (if modQueries.txt exists, then modQueries_philippe.txt is created...). Of course if there is no equivalent .txt file in the folder, it will be created at first export.
At the end of the period, we would get in our folder the following files
modQueries.txt, being the first "original", last common version of the module
modQueries_Philippe.txt, with Philippe's modifications
modQueries_Denise.txt, with Denise's modifications
As the module was not modified by other developers, their export did not lead to the creation of a specific modQueries_developersName.txt file
If for any reasons Denise exported many times her module, only the last version is in the comparison folder.
We can then compare (with a "text file" comparer) the different versions and create the "updated" version of the module. We have a screen giving us the number of objects in the comparison folder, number of version for each object, and it is even possible to open the file comparer directly from the developer's interface (We use "File Compare Tool" which has a command-line mode and can then be started directly from Access).
The forms compare issue is quite special, as one of our rules is to have no specific code in our forms (please see here for more details). Forms are then only for display, so usually we do not even compare them. We just make sure that each one of them is updated by only one person (which is quite logical).
The table compare issue (we have local tables) can be only made between mdb files. As we export one text file per module, we also export one mdb file per table. We have a small routine allowing us to identify table differences at the structure level or at the record level.
After each comparison procedure, a subroutine will use all the objects available ini the comparison folder and create a whole new clean mdb file from scratch. This is the new developer's version. Every developer can then copy it on his computer and continue his work.
Developer's versions do not have numbers, but contains last client version number.
The client version, with limited stuff, automatically distributed to users
Each developer has the possibility to build a "client" mdb for final users. This mdb is created from scratch, in a way quite similar to our developer's version, but not all objects are exported. Some specific switches are turned off (special keys, access to code, etc). This mdb holds a version number as a property. The version number is used to build the name of the mdb file.
At production time, this mdb file is zipped and placed in a specific "distribution" folder. Each time a user starts the app, it will automatically check this folder to see if a new version is available. If yes, the client mdb file is updated from the distribution folder, and the app is restarted.
This distribution folder is replicated at night time with our overseas agencies. Users abroad will then be able to install the new version on the following day.
Following the direction provided by Yarik we settled on continuing developing in Access using the Access Add-in Source Code Control, the SVN SCC API Plugin by PushOk Software and Subversion. This stack provides us with seamless Access integration, full-backup and restore and an open version control system.
We had to install a hotfix to Access 2003 and make sure the default database file type matched our database file type to make it work.
We will continue to update this answer with our findings.
Have look at this thread:
How do you use version control with Access development?
Sounds like a terribly painful way to do team development. If you have any options for porting to another environment like VS2008 that would be my recommendation.
There is no easy way to work on Access as a team and even version control might be a bit tricky.