Solved I used to be able to copy objects from one database to another but now I get error code 3734 (1 Viewer)

spaLOGICng

Member
Local time
Yesterday, 16:42
Joined
Jul 27, 2012
Messages
163

The database has been placed in a state by a user on a machine that prevents it from being opened or locked (Error 3734)​


I have a client that likes to make changes to his version of the application. I maintain the developer master copy and so I need to merge his changes, etc., with my copy and will send it to me to be merged.

I used to be able to have the two versions open side by side and just select the objects to be copied and paste to the other, but now I am unable to. I receive the following error:

1712847061082.png


I am the only person that has the copies open on my computer. I do keep all files on OneDrive, but tested for that being the issue by copying to a local folder on my hard Drive. I still receive the error.

My PC is a Dell XPS 8950 32g Ram 1tb SSD. My MSO is Microsoft® Access® for Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176) 64-bit.

I moved the Files to my old PC with a 1tb HD and get the same error message.

Has anybody encountered this issue and if so, how did you overcome it?

Also, does somebody know of a Tool to export selected objects to another Database? The Export feature in Access, one at a time, has a lot to be desired. The Import feature is great, but it does not display timestamps for updated objects which would be very helpful determining which should be imported. Additionally, it will import a second copy if it already exists. Having the ability to decide to create a copy overwrite would be great.

Any information on this would be greatly appreciated. I will probably just create my own tool. I have one partially built somewhere, but it has been ages.

Thanks!
 
At first blush, that sounds like a permissions problem in that Access THINKS it should be able to open the lock file (.LDB or .LACCDB) but can't. So maybe verify that you can create and delete files in the folders in question. Also, see if there already exists a lock file but for some reason, the lock file is itself locked or damaged. Test whether, when the DBs in question are closed, that you don't have the lock file, or if you do, that you can delete it. (However, I have my doubts because moving the file should have fixed the problem.)

Use the file (right click) >> Properties >> Security to verify that the files in question have Modify access level. You may have to step into the Advanced option on the security panel to look at "effective permissions" for a specific user (you, since you are the one being blocked.)
 
At first blush, that sounds like a permissions problem in that Access THINKS it should be able to open the lock file (.LDB or .LACCDB) but can't. So maybe verify that you can create and delete files in the folders in question. Also, see if there already exists a lock file but for some reason, the lock file is itself locked or damaged. Test whether, when the DBs in question are closed, that you don't have the lock file, or if you do, that you can delete it. (However, I have my doubts because moving the file should have fixed the problem.)

Use the file (right click) >> Properties >> Security to verify that the files in question have Modify access level. You may have to step into the Advanced option on the security panel to look at "effective permissions" for a specific user (you, since you are the one being blocked.)
I have full control of all Files and Folders. I am the Owner and Administrator of all my machines and not attached to any Domain Controller. I do have UAC enabled but I do not get the UAC permission window when I install programs etc.

Interestingly enough, I looked at my Local Folder Permissions and the Read Only Checkbox was marked as "-", not Check or Unchecked. I changed the Read Only Attribute and applied the change. When I returned it is "-". I tested this for read only and not, and in both cases, it reverted to "-".

I then looked at permissions on the Folder/Files. Administrators have Full Control. Users had limited control. I changed Users to Full Control. Still could not export objects.

I might add that my OS is Windows 11 Pro. My old PC has an evaluation version of same.

This is something that has happened in the past, but only when I made a change to one of the applications. I would normally just close and reopen, even when they were located on OneDrive, and could copy without issue. This began recently and I just cannot pinpoint it.
I also thought it could be attributed to the "Track Changes" Feature in Access so I disabled it in my developer copy, to no avail. I remove those features when I publish a User Copy.
 
My position with software I create for clients is - if you modify it, you own it. I refuse to merge their changes into my version of the app. They can tell me what they want changed, and I will make the changes to my version.

To do what you want to do is awkward because, Access won't let you copy and paste if any objects are open. It also seems to remember that they were open and so closing them doesn't reset the "flag". You have to close the database.

How are you determining what the user changed? Are you checking every single property of every single object? Are you comparing the code, line by line? Are you comparing macros line by line? This is pretty close to impossible to handle manually which is why I flatly refuse to do it.

I'm probably going to hate myself in the morning for even trying to help you with this but here goes.

In the client's version:
1. Open the navigation pain and sort it descending by last update date. This will get all the changed objects to the top of the list.
2. Then you need code to do the export. Create a form if you want to automate it or just retype the names.

Replace the object names with the name of your form, report, macro, or module and export each object
Application.SaveAsText acForm, d.Name, sExportLocation & "Form_" & d.Name & ".txt"
Application.SaveAsText acReport, d.Name, sExportLocation & "Report_" & d.Name & ".txt"
Application.SaveAsText acMacro, d.Name, sExportLocation & "Macro_" & d.Name & ".txt"
Application.SaveAsText acModule, d.Name, sExportLocation & "Module_" & d.Name & ".txt"

In Your version, you need to import the text files:
Here's a better routine for importing one at a time. The form has a combo that picks the type and a textbox where you can type the name of the file to be imported or use the file dialog to pick it for you.
Code:
Public Sub ImportSingleObject()
On Error GoTo Error_Proc
    Dim ObjName As String
    ObjName = Me.txtDBName & "\" & Me.cboObjectType & "_" & Me.cboObjectName & ".txt"
    Application.Application.LoadFromText GetArgumentValue(Me.cboObjectType), Me.cboObjectName, ObjName
    MsgBox "Selected object has been imported.", vbInformation
Exit_Proc:
    Exit Sub

Error_Proc:
    MsgBox Err.Number & "-" & Err.Description
    Resume Exit_Proc
End Sub

Good luck but you really need to stop them from doing this. If the client is a competent developer, he doesn't need you. If he isn't a competent developer, he is just making messes for you to clean up.
 
I have seen this error, when another (perhaps hidden) instance is already running on my desktop.
I use Task Manager > Details > search for msaccess.exe to find such instance and kill it.

It has nothing to do with opening two databases at the same time. That ability has not changed.
 
After a search, I found what may be a relevant article.


How it applies specifically to your case, I don't know for sure, but it LOOKS like maybe there is an object open for design work.

Here is a link you can get to if you follow the links in the first referenced article:


I am thinking that at least part of the problem may be that the database file in question (that came from the user) was still open for design mode by that user's operations when the computer was shut down or when the Access session was forcefully terminated. I.e. a ragged save.
 
After a search, I found what may be a relevant article.


How it applies specifically to your case, I don't know for sure, but it LOOKS like maybe there is an object open for design work.

Here is a link you can get to if you follow the links in the first referenced article:


I am thinking that at least part of the problem may be that the database file in question (that came from the user) was still open for design mode by that user's operations when the computer was shut down or when the Access session was forcefully terminated. I.e. a ragged save.
Hi Doc,

I believe this is a technical issue not related to the conventional or typical causes for this error. I have been working like this for a long time, and only recently ran into the issue. Nothing has changed except for updates to Windows and Office.
 
I have seen this error, when another (perhaps hidden) instance is already running on my desktop.
I use Task Manager > Details > search for msaccess.exe to find such instance and kill it.

It has nothing to do with opening two databases at the same time. That ability has not changed.
Hi Tom,

I have seen this issue as well. Where, for instance, and DAO Record Set was not closed and would orphan the DB in an open state. That is not the case here. I did check for that. I compacted and repaired both DB's, then re-opened from a clean slate holding down the shift key to bypass they start up procedures.
 
I agree with Tom. Error 3734 can occur when a database is already open as a background process

Using Access 365 & Windows 10, the functionality has not changed. I have just re-tested to confirm this
In fact I created a video on this topic a couple of years ago

I don't have Windows 11 but have not heard of any other reports that this functionality has been removed
There are of course several reasons that may prevent dragging objects from one database to another, some of which have been stated above.
I've also found it fails if the two databases are on different monitors
However, the drag & drop method does still work

As a test, try seeing whether you can create database object shortcuts on the desktop with only one database open
 
I agree with Tom. Error 3734 can occur when a database is already open as a background process

Using Access 365 & Windows 10, the functionality has not changed. I have just re-tested to confirm this
In fact I created a video on this topic a couple of years ago

I don't have Windows 11 but have not heard of any other reports that this functionality has been removed
There are of course several reasons that may prevent dragging objects from one database to another, some of which have been stated above.
I've also found it fails if the two databases are on different monitors
However, the drag & drop method does still work

As a test, try seeing whether you can create database object shortcuts on the desktop with only one database open
There are no open background processes. I open the DB's from scratch. I even rebooted my PC.

I have already built a bulk selectable export feature. I typically do not use any gifted, purchased, or otherwise 3rd party tools, as I am a developer myself. I have been in this business for over 30 years. While I do not claim to know it all, I tend to develop my own solutions. I do appreciate it though.

I only reached out here for a possible solution that is a new occurrence and does not fit the conventional or common place causes for this error. If I happen to find the issue, regardless of how silly it is, I will be sure to comment here what it was.
 
I have a feeling the issue is related to a background process, not an access application, but a background process running at the OS level, as a Service or Task. Investigating.
 
To determine whether something else has opened the DB...

Open Task Manager. Under the Processes tab, if Access IS open (as MSACCESS.EXE, 'cause that is the formal task name), you should be able to see it. If more than one copy of Access is open, you should see THAT by the Access line having ">" in front of it. Click that ">" to open the instances running Access to verify that more than one is running.

Still on Task Manager, click on Details. You will see the names of each process and its PID (Process ID). Note the names and PIDs for each copy of Access you find open. (However, if you ARE right and the problem is some other process, there might be no Access processes to be found.)

Regardless of whether you are right or wrong about it being some other process,...Select Performance. At the bottom click on the link to Resource Manager. From RM, select the Disk tab. You SHOULD see three horizontal regions for Processes With Disk Activity, Disk Activity, and Storage. You can ignore the Storage section and click on the bar to minimize that region. You can drag the bars to expand or shrink the areas. The one titled Disk Activity lists the image, PID, and File Spec for each opened file. (Also shows activity levels.) This is essentially the "active file handles" list.) See if your DB file is there. If so, you will find the PID and image name of the thing that grabbed your file.

It is totally possible that this will find nothing. What I'm doing is showing YOU how to determine that nothing active has your file open. I fully believe that it is a state of the file, not the action of some other task. First, because you've done this after a reboot. Second, because you've done it on more than one machine. I think this is a FILE problem, not an O/S or interfering task. But if it will help you to verify that no file handle is open to that file, here's how you prove it.
 
I only reached out here for a possible solution that is a new occurrence and does not fit the conventional or common place causes for this error. If I happen to find the issue, regardless of how silly it is, I will be sure to comment here what it was.

My response was for anyone reading this thread.
I do suggest you try creating database object shortcuts on the desktop with only one database open. At the very least, that's one thing to eliminate
 
My response was for anyone reading this thread.
I do suggest you try creating database object shortcuts on the desktop with only one database open. At the very least, that's one thing to eliminate
Understood. I did search for a possible solution before creating the thread. Most of what you and others have mentioned here I had found on earlier threads. I do appreciate it though.
 
To determine whether something else has opened the DB...

Open Task Manager. Under the Processes tab, if Access IS open (as MSACCESS.EXE, 'cause that is the formal task name), you should be able to see it. If more than one copy of Access is open, you should see THAT by the Access line having ">" in front of it. Click that ">" to open the instances running Access to verify that more than one is running.

Still on Task Manager, click on Details. You will see the names of each process and its PID (Process ID). Note the names and PIDs for each copy of Access you find open. (However, if you ARE right and the problem is some other process, there might be no Access processes to be found.)

Regardless of whether you are right or wrong about it being some other process,...Select Performance. At the bottom click on the link to Resource Manager. From RM, select the Disk tab. You SHOULD see three horizontal regions for Processes With Disk Activity, Disk Activity, and Storage. You can ignore the Storage section and click on the bar to minimize that region. You can drag the bars to expand or shrink the areas. The one titled Disk Activity lists the image, PID, and File Spec for each opened file. (Also shows activity levels.) This is essentially the "active file handles" list.) See if your DB file is there. If so, you will find the PID and image name of the thing that grabbed your file.

It is totally possible that this will find nothing. What I'm doing is showing YOU how to determine that nothing active has your file open. I fully believe that it is a state of the file, not the action of some other task. First, because you've done this after a reboot. Second, because you've done it on more than one machine. I think this is a FILE problem, not an O/S or interfering task. But if it will help you to verify that no file handle is open to that file, here's how you prove it.
I had already gone through all those steps. The background process or service that I am referring to would be unrelated to Access. I have even seen where proactive anti-virus cause issues in the past, but I did rule that out.

When I said that I tested on more than one machine, I had copied the files to that machine. I did not open through the network.

The one thing that I failed to mention is that the Tables are linked to SharePoint Lists. I did rule that out as well as I tested one two very basic database applications with only a couple of objects, to no avail.
 
When I said that I tested on more than one machine, I had copied the files to that machine. I did not open through the network.

That is why I suggested that the problem is with the file itself, not an external process.
The background process or service that I am referring to would be unrelated to Access.

Which is why I suggested using Resource Manager to see if something actually had the file open.


This is the point I'm making: I fully expect that nothing has it open. Nothing has it access-locked (note small "a" in this case.) Something is wrong with the file itself. I have been merely suggesting ways to prove me wrong by finding the culprit.

You previously looked at permissions, which move with the file as part of its properties list. Copying the file would probably copy its permissions. Manually taking ownership of the file might help, might not. I think it is something your user did when prepping that file to be sent to you, and that copy of the file is now trash, corrupted in some way. You've tested other files. They work. You've copied the files to another machine. The copied file fails.

I would get this particular client to try to send you a new, clean copy of the file made more carefully including making the copy while the app is closed and assuring that the copy medium is dismounted (ejected is the word Windows uses) and physically removed before anything else.
 
As I said earlier, I can recreate this error at will.


Both databases need to be "pure" and have no object open currently or open since the db was opened because even if you close all open objects in both databases, once you get this error, you need to close one or both dbs and open them by holding down the shift key and remember to NOT OPEN ANYTHING while you are trying to do the copy/paste.

I like the export to text. It isn't as picky. You can make yourself an app to do this for your situation. One problem is that the date/time stamp in the Navigation Pain (sic) is accurate but the last update date/time in MSysObjects is not so this is very difficult to automate. If you keep the Nav Pane open, you can just type the object names into a temp table. Then you can run the export to text which exports the files to a specific folder.

Then in your database, you do the import. You open a file dialog to the export folder and loop through the files found there. You can use your naming convention to figure out the object type and the name of the object. Your code can delete or rename the existing object and then run the import from text command. The code I posted has most of what you need.
 
Both databases need to be "pure" and have no object open currently or open since the db was opened because even if you close all open objects in both databases, once you get this error, you need to close one or both dbs and open them by holding down the shift key and remember to NOT OPEN ANYTHING while you are trying to do the copy/paste.

I disagree with part of this statement. Not sure what 'pure' means in this context.

1. I can safely drag & drop almost (*) any object: which isn't open. Other unrelated objects can be open without problems
2. The object being dragged must first be saved if any changes have been made.
3. The two application windows must be on the same monitor (as previously stated) and should not overlap
4. Dragging a linked table imports it which is probably unwanted behavious. If you repeat the process, you can overwrite as a linked table

...almost(*) ...
However I can't drag any object from a database with linked Sharepoint lists. Not even local tables totally unrelated to SP.

1712939198697.png


Closing and reopening has no effect.
I suspect SQL Azure / Dataverse may behave in the same way (not tested)
Other types of linked table e.g. SQL Server / Access / DBF / Otlook / CSV / Excel / HTML aren't an issue
 
There might genuinely be a corruption. I would be inclined to close the database, copy it for safety, and then open it as a single user and try a compact and repair, or maybe even import everything into a new database.

There was an access issue a year or two ago, maybe longer, that kept producing that issue. Maybe something like that is catching you out.

By the way, I agree with @Pat Hartman . I wouldn't want anyone making changes in my databases.
 
That is why I suggested that the problem is with the file itself, not an external process.


Which is why I suggested using Resource Manager to see if something actually had the file open.


This is the point I'm making: I fully expect that nothing has it open. Nothing has it access-locked (note small "a" in this case.) Something is wrong with the file itself. I have been merely suggesting ways to prove me wrong by finding the culprit.

You previously looked at permissions, which move with the file as part of its properties list. Copying the file would probably copy its permissions. Manually taking ownership of the file might help, might not. I think it is something your user did when prepping that file to be sent to you, and that copy of the file is now trash, corrupted in some way. You've tested other files. They work. You've copied the files to another machine. The copied file fails.

I would get this particular client to try to send you a new, clean copy of the file made more carefully including making the copy while the app is closed and assuring that the copy medium is dismounted (ejected is the word Windows uses) and physically removed before anything else.
Hi Doc,

I initially thought we were onto something here with your insight into the resource manager...

I reviewed the Resource Monitor, and I did see a process unrelated to Access but is part of the SysMain Service that controls restricted folders. My search started with "SuperFetch" that morphed into "SysMain", that managed the svchost.exe (LocalSystemNetworkRestricted) Process. I disabled the Service and rebooted but this did not render the application to me. I cannot find any other process that is referencing the Applications or the Folder they reside in.
 
Last edited:

Users who are viewing this thread

Back
Top Bottom