I have a Access Database running as a normal file on a shared drive. Some tables from this database are available to users to read through Excel Files with ListsObjects.
These ListObjects need to be refreshed regularly to be up-to-date. Currently I am doing that manually.
I want to do this automatically by running a VBA code in the access database to open each file and in each files all the ListObjects to refresh them.
However, if I run the ListObject.refresh() method I get an error message that the database is blocked. If I do the refresh manually it works perfectly. In both cases I have the database open, so that can't be the problem.
This is the error message:
The database has been placed in a state by an user ("here is my user ID") that
prevents it from being opened or locked. (Error 3733)
Thank you for any suggestions.
Here is the part of the code:
Set ExlFile = app.Workbooks.Add(myWB)
For Each mySheet In ExlFile.Worksheets
For Each myLO In mySheet.ListObjects
myLO.Refresh
Next
Next
UPDATE:
If I use the function compact and repair on the database, it works for 3-5 files and then it stops working again.
Does anyone know what Application.CompactRepair does? I have a very bad solution for my problem now, I added Application.CompactRepair to each iteration. Now it works but of course it takes very long. It seems to me Application.CompactRepair somehow resets some status in the DB and it would be a better solution to do that directly.
Related
I built an excel tool that captures information, our company has rolled it out to 500 users without telling me. It seems to work ok other than sometime the access database locks in an odd read-only mode, but there doesnt appear to be anyone in the file?
Excel does ODODB connection to access with this string:
Connection.mode = 16 + 3 'adModeShareDenyNone + adModeShareReadWrite
Any thoughts on how to avoid these odd lock outs?
Background:
I have an Excel file that is a workflow tool for one of our teams. One of the key processes is importing data from csv files and then uploading into MS Access. This part of the process works fine every time, no errors.
I added a new process to the tool, similar to the one mentioned above, this process scans data from one sheet and if a row meets a criteria it is copied into another sheet. Once the analysis is complete it gets uploaded into MS Access using the following code:
objAccess.DoCmd.TransferSpreadsheet acImport, acSpreadsheetTypeExcel9, "tb_age_extract", Application.ActiveWorkbook.FullName, True, "AGEUPLOADDATA"
The strange thing is this will run ok for me but when the users try and run it they get a runtime error 3051, the full error message is:
The Microsoft Access database engine cannot open or write to the file '\Folder1\Folder 2\FileName.xlsm'. It is already opened exclusively by another user, or you need permission to view and write its data.
I ran a test using a 50 count loop, all 50 runs ran ok with no errors, then the user tries to run it and they get the error. I have also experienced the error as well on my machine.
What is puzzling is the error is sporadic.
Has anyone experienced something similar with a 3051 error?
I have an Excel Macro Workbook (binary extension) that suddenly has developed 2 issues occasionally (sometimes it runs fine).
#1 Issue - Occasionally there is an error on Line 5
It appears the connection does not open. We get the error:
Microsoft][ODBC Microsoft Access Driver]General error Unable to open registry key Temporary (volatile) Ace DSN for process 0x7f8 Thread 0x1174 DBC
#2 Issue - Occasionally there is an error on Line 7
It appears the SQL can not run. It indicates the Worksheet tab can not be found even though it does exist. Note for this error we have no issue with Line 5 (Open Connection). The error that displays is:
[Microsoft][ODBC Excel Driver] The microsoft jet database engine could not find the object 'Worksheet Name'. Make sure the object exists...
For Issue #2 once we close the error dialog box and THE MACRO GETS DELETED !!!
Notes
The code module has not been changed in years Some days we get no errors/issues
This issue occurs for multiple Excel workbooks run by multiple people that run different VBA code blocks. However 1 of the code blocks is the same across all these macros which is the code snippet above.
The source data has not changed in years in terms of formatting or volume.
All these workbooks are on a Network server.
We are on Windows7/Excel 2010/ODBC Excel Driver (xls xlsx xlsm xlsb)
14.00.7180.5000
Code Snippet
1-Set adoConn = Nothing
2-Set adoRS = Nothing
3-Application.EnableCancelKey = xldisabled
4-strConn = "Driver={Microsoft Excel Driver (*.xls,*.xlsx,*.xlsm,*.xlsb)};DriverId=1046;Dbq=" & strFileName & ";IMEX=1;"
5-Set adoConn = New ADODB.Connection: adoConn.Open strConn
6-Application.EnableCancelKey = xlInterrupt
7-Set adoRS = New ADODB.Recordset:adoRS.Open Source:=strSQL,ActiveConnection:=adoConn
I'm curious as to why you're using ODBC to connect Excel to another Excel file, as opposed as to linking the data directly.
Intermittent connection problems point to a network issue. I would suggest removing and re-creating the ODBC connection, but I'd first want to confirm the value of strFileName as referred to in the connection string. Is it an actual server on your internal network, or an external source? (ie, is it a UNC path?)
An intermittent Unable to open registry key error likely sounds worse than it is; when having connection problems, Windows & Excel will easily get confused as to what the real problem is.
It sounds like your setup has been in place, possibly un-maintained, for a long time. When is the last time the client and server were rebooted? (Should be nightly.) Defrag, disk cleanup, etc?
As for the issue of the macro "getting deleted" when you close an error dialog, I'd need to see proof of that. I think you're misunderstanding something, unless you're re-writing the macro from scratch each time this happens..
I have a data feed connection in excel. I'm trying to refresh a data feed connection using vbscript. Here's how I try to refresh the connection.
Set oWorkbook = oExcel.Workbooks.Open('<excel file name/path>')
oWorkbook.Connections(1).Refresh
The total number of records returned by the data feed(OData) is actually huge and the conection isn't stable. Hence, I often get the error stating that "The connection is closed" while trying to refresh the connection from excel manually. A snapshot of the error below. Whenever I get this error, I try refreshing the connection again and this results in successful refresh most of the times.
I want to achieve the same result in vbscript as well. When I refresh the connection using vbscript, I get the same error and my script stops running as its unable to capture and handle the error.
In the documentaion I see that I can capture errors only if its OLEDBError or ODBCError. I'm not able to find the similar ways to capture DataFeedConnection error. Is there any way to capture the DataFeedConnection errors?
Edit: To update you with more information on the vbscript, the script picks up multiple files from the current folder, refresh the first or second connection depends on the file name and then compare certain values before and after refresh to make sure the refresh has happened successfully and then decide saving or closing the file based on the comparison results. The reason for comparison is there are some times refresh brings only partial data.
How about the following, adding an "On Error GoTo" then using a msgbox to display the error description:
Sub Foo()
On Error GoTo WhatHappened
'Your code here
WhatHappened:
MsgBox Err.Description
End Sub
Excel_Obj = CREATE OleObject
Excel_Obj.ConnectToNewObject( 'excel.application' )
Excel_Obj.Workbooks.Add
Excel_Obj.Application.ActiveWorkbook.WorkSheets.Add
Excel_Sheet = Excel_Obj.Application.ActiveWorkbook.WorkSheets[1]
//EXAMPLE
Excel_Sheet.Cells[1,1] = 45
Excel_Obj.Application.ActiveWorkbook.SaveAs(ls_file,56) //csv
//where ls_file = the Opened File
error happened after / during saveas.
try catch throw "error calling external object..in click..line.. saveas.."
--
i want to state to the user that the excel file is open therefore cannot be overwritten properly. I used a try catch and throwed a proper message but before the messagebox for the catch event happens, the PB execution error R0035 happens. any solutions or proper way to know if the excel file is open.
You might be able to check if the file is open first, have a look at this answer:
how to check if file is opened in excel using OLE (leaves excel process open)
I'd try a PowerScript FileOpen () call with a LockReadWrite! parameter to see if it can be opened, followed immediately by a FileClose () if it was successful. (I think this is a PowerScript-specific variation on the DXL solution Colin linked to.)
Good luck,
Terry
Have you tried approaches similar to these?
Using Win32 API:
http://www.rgagnon.com/pbdetails/pb-0030.html
Using PB function fileopen()with the (default) exclusive rights set:
http://www.tek-tips.com/viewthread.cfm?qid=1610670
In other words, see if the file can be opened exclusively before connecting to Excel or making the CSV?
You will have to turn off the option to break into the debugger for that exception to see the exception handling work in the IDE. Look for the Help topic "Exception Settings dialog box" for details. Once you see it's working I recommend you set it back to break into the debugger, since you'd normally want to see what threw the error.
You cannot use ole when document is open( even you set lock write) by the user and not by apllication.
my approach, I have been using many times till now:
Check excel is open or not, use use can use api or wsh script in the internet to check app opened. If opened do not run save as and tell user to close excel and not run it for while for while.
if you user run excel and your program still running active workbook and worksheet application will be switch to excel that opened by user ( imagine it wrong written data).
Change your code as below
if Excel_Obj.ConnectToNewObject( 'excel.application' ) <> 0 then
messagebox("warning", "could connect to excel", stopsign!)
RETURN
end if
just for knowledge another technique is DDE call, but not common today and most complicated.
Happy coding From pb developer.