We're currently running into an issue with an Access 2007 database for a client. They've got Excel 2007 documents attached to records within the database. Whenever changes to the document are made, they are overwriting each other, and we're not sure exactly why. This is happening with different records, and all of the attached documents are named differently. We've tried adjusting the different locking schemes, but this doesn't seem to resolve the issue.
Any ideas? Are we missing something?
the attached documents are overwriting other attached documents the key is they are open at the same time by different users.
They are making the changes using excel saving them to a temp folder and then access saves the documents through its interface. This is pretty standard.
#dvhh Please refrain from access bashing. I agree access sucks. This is a system the client already had in place that I need to get working or give a reasonable response to why this particular piece is not working and can not be fixed.
#Remou access is limited there are better options out their Access has its place and its uses for business please leave it at that.
Related
In our company, we created a small Access database, which was in a network folder for everyone to access it.
After a while we decided to split it into a backend and a frontend. The new frontend is at the same location the original data was while the original data, serving as the backend now, is in a subfolder of the folder it used to be located in, so all relevant data is accessible to the the employees as it has always been.
The current problem is, that today, most of the time both the BE and the FE have their ".Iaccdb" files showing up and if you try to open any of the two, BE or FE, it will say, that a user is using the database in the exclusive mode.
I guess solving the problem at hand isn't the main issue here. What I rather like to know is, WHAT must have happened, to cause both files to behave this way.
I heard about this happening to either the BE or the FE, but never both simultaneously.
Never use a shared frontend:
Deploy and update a Microsoft Access application with one click.
I found out what caused the issue and in doing so also have to apologize for omiting one relevant detail: The old file I started with also had connections to Sharepoint lists.
Because of that, I couldnt just use the split function as it doesn't work if you're database is connected to Sharepoint.
So my workaround was to copy the access file in the upper folder as the new FrontEnd. In this new file/FE, i just created links to the old file's table, which now serves as the backEnd.
As I said, there were connections in the old file/BE.
When I first tried the FE, it worked properly. only when someone already opened the FE and another one wanted to do the same, the issue of users blocking each other appeared.
My solution was to get rid of the SharePoint connections in the old file/BE and now everything works smoothly.
I have been working on a submission form for two of our employees' to enter tax data. It is an InfoPath 2010 form, which is connecting to an Access 2010 accdb. The purpose of the form is to pull related data from two source tables (one from the old dB that was used, and the other from APX which houses additional information) to prefill as many fields as possible. Everything works fine when running it from my computer, or directly off our server. The problem I am running into now, is that our two users have access to the files, can open them with InfoPath Filler, but upon opening, they get the "InfoPath cannot connect to the data source...". The funny thing is, is that last week, they were able to connect and submit data with no problem (then one day I came back from lunch and it no longer worked). How I had to originally set them up was to create a certificate, make the forms full trust, added both user ID's as being able to have read write access. When I run the form from my desktop it works without a hitch. I even tried remapping to a mdb to see if it was a version issue. The dB is stored on a shared domain, \testdomain\, for arguments sake. Then they access the form via the same directory. Just to note, SharePoint is not connected in any way. All the searches I have done have yielded no solutions. I am thinking it is a networking issue, and have a meeting with the network admin in a few hours. But, what I can't figure out, is how it worked before, and not now. Does anyone have any suggestions or thoughts on what could be causing this? Just to clarify, I can run the same xsn form they run, from the same server location, without having the issue they do. I truly appreciate anything anyone might be able to offer!
Ok, finally figured out what was causing the problem (totally feel dumb). Apparently the servers used randomly get backed up, and when they do, the permissions get overwritten. If anyone else runs into this, review the access permissions for the directory and all the files. Thanks Nathan for your advice!
I have a MS Access 2013 file that I am using. There are two possibly related concerns. For some context, this is an MS Access 2013 file with some forms and some tables and a bit of VBA for the logic of how those two interact. For versioning, the file has been copied and pasted with a datestamp on it for the newer version.
The first concern is that all the file sizes for the various files is exactly the same, even though data has been added and some changes to the forms were made.
The second concern is that when I right click on a table and go to table properties, it says "Shortcut to Table (Local): table_name" where table_name is the name of the table. It appears that this is a shortcut to a table somewhere, but I'm not sure where. The forms are also shortcuts to forms, but I don't see the destination form in my file anywhere, even after unhiding system objects. My questions regarding this are: how did this happen (I was assuming it had something to do with the fact that I copied and pasted the file) and where is the file that these are a shortcut to?
Everything seems to work fine, but I'm concerned that if one of the legacy files gets removed that I might lose some data. Is my data being stored within this file, or did it get split somehow and the data is being stored in a different file somewhere? I just want to have a better grasp of what exactly is going on.
I feel like I have a good handle on the SQL and a pretty good grasp of the VBA, but the MS Access specific nuances are something I'm still gaining familiarity with.
Well, it seems it was as simple as changing the view in your navigation pane to something else than custom!
I am completely perplexed.
A colleague's got a database issue. I noticed that the (internal) software that created the local database file with the problem, uses programmatic access to MS JET, which meant an easy first step was to see if MS Access (2010) was happy with the database - and then fix, export/import or repair, as a first step.
I copied the stand-alone local Jet data file to a non-networked virtual machine (so no chance of external data), and MS Access opened the db file easily, but I can't make sense of what I'm seeing.
MS Access is configured on that system to show all hidden and system objects, confirmed since the Access system tables in the file are all visible and can be opened. These are my observations:
The object browser lists the usual MS system tables, and a bunch of SELECT queries (which look correct) of the form SELECT (FIELD LIST) FROM (OTHERTABLENAME) WHERE (FIELDNAME=VALUE), nothing more.
The select queries show the usual grid with valid data records when opened, and the data looks correct as well.
No data tables with the given names are showing in the object browser interface.
The given names are listed as objects of the database, in the system table MSysObjects.
So..... the underlying data tables ARE named in MSysObjects, and seem to be true data tables... but they are NOT being listed in the object browser and I can't figure how to open their datasheets (although MS Access' system tables are, and "Show hidden/system" are both enabled)... and the tables surely do exist in the file since an apparent SELECT query is pulling their data from them, and the file is on a clean non-networked machine with no other sources reachable.
Any ideas? I want to check the underlying data but ... whats going on?
When I examined your database, I discovered the reason you can't access the tables normally is because the authors of the internal application which created the db file implemented measures to prevent normal access.
I advise you to contact them and your managers to get authorization and assistance to view the data.
Also, please be cautious with this question. A suspicious person might uncharitably interpret your question as a disguised request for hacking help. Please note I am not accusing you of anything underhanded ... simply asking you to notice how your question might be perceived. And, if that were to happen, I don't know what the consequences would be on Stack Overflow, but I can't imagine it would be good. So please be careful.
We have an access database on a file share that has permissions for everyone in the department to access. The problem i am having is that when multiple users try accessing the database at the same time they are unable to do this. One user can open the database fine but when another user tries to simultaneously, they double click the file icon, get an hour glass for a split second and nothing happens after. We are using Server 2003 as our domain controller. All permissions have been verified on both a domain level and in the access database under tools-options-advanced and setting relevent permissions to shared and no locks. Do you know what could be causing this issue with a "dead link" when user try to open the file simulateneously?
Any help is greatly appreciated.
Thanks.
Ignore the naysayers - Access is perfectly fine for a small number of users. Either you have the default Access settings to open dbs exclusive which will lock out other users or there is some weird network problem.
EDIT
- noticed you already have default shared access
- is record-level locking on?
- also try giving user full control of the shared network folder (Access needs read/write/create/delete to be able to create and delete the ldb file)
This issue occasionally happens to Access databases for almost no apparent reason. Of the suggested responses by Microsoft, you are already doing the second (opening from within Access) but I believe the first provides somewhat of the answer you are looking for.
In the target of the shortcut, include
the path of MSAccess.exe
According to Microsoft Help and Support
When you say share permissions, do the users have full permissions? Full permissions are needed because the share file (.ldb) must be created and deleted.
I am just recently experiencing the same issues, only one person can open the database. We only have 3 people accessing the same database through shorcuts on our desktop.
Now according to Microsoft we need to include the database path in our shortcut, I will tried that. They acknowledge this problem.
MS Access is not worth the trouble in a multi-user setup.
Your time is better spent converting the database over to a server-based RDBMS such as SQL server while you still have hair.
Believe me, you will have to do it sooner or later anyway! Sorry for the bad news.