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?
Related
PROBLEM: I've hit a troubleshooting wall and hoping for suggestions on what to check to get past an issue I'm having with an internet site I'm working on. When reading data from a spreadsheet using NPOI (C#), sometimes (not all the time) the row reading stops after just ten rows.
Sorry for the very long post but not sure what is/isn't useful. Primary reason for posting here is that I don't know the right question to ask the Great Google Machine.
I have an intranet site where I'm reading an XLSX file and pushing its contents into an Oracle table. As you can tell by the subject line, I'm using NPOI. For the most part, it's just working, but only sometimes...
In Oracle, I have a staging table, which is truncated and is supposed to be filled with data from the spreadsheet.
In my app (ASPX), users upload their spreadsheet to the server (this just works), then the app calls a WebMethod that truncates data from the Oracle staging table (this just works), then another WebMethod is called that is supposed to read data from the spreadsheet and load the staging table (this, kinda works).
It's this "kinda works" piece is what I need help with.
The spreadsheet has 170 data rows. When I run the app in VS, it reads/writes all 170 records most of the time but sometimes it reads just 10 records. When I run the app from the web server, the first time it fails (haven't been able to catch a specific error), the second and subsequent times, it reads just ten records from the spreadsheet and successfully loads all ten. I've checked the file uploaded to the server and it does have 170 data records.
Whether the process reads 10 records or 170 records, there are no error messages and no indication why it stopped reading after just ten. (I'll mention here that the file today has 170 but tomorrow could have 180 or 162, so it's not fixed).
So, I've described what it's supposed to do and what it's actually doing. I think it's time for code snippet.
/* snowSource below is the path/filename assembled separately */
/* SnowExcelFormat below is a class that basically maps row data with a specific data class */
IWorkbook workbook;
try
{
using (FileStream file = new FileStream(snowSource, FileMode.Open, FileAccess.Read, FileShare.Read))
{
workbook = WorkbookFactory.Create(file);
}
var importer = new Mapper(workbook);
var items = importer.Take<SnowExcelFormat>(0);
/* at this point, item should have 170 rows but sometimes it contains only 10 with no indication why */
/* I don't see anything in the workbook or importer objects that sheds any light on what's happening. */
Again, this works perfectly fine most of the time when running from VS. That tells me this is workable code. When running this on the web server, it fails the first time I try the process but subsequently it runs but only picking up that first 10 records, ignoring the rest. Also, all the data that's read (10 or 170) is successfully inserted into the staging table, which tells me that Oracle is perfectly okay with the data, its format, and this process. All I need is to figure out why my code doesn't read all the data from Excel.
I have verified numerous times that the local DLL and webserver DLL are the same. And I'm reading the same Excel file.
I'm hitting a serious wall here and have run out of ideas on how to troubleshoot where the code is failing, when it fails. I don't know if there's something limiting memory available to the FileStream object causing it to stop reading the file prematurely - and didn't run across anything that looked like a resource limiter. I don't know if there's something limiting the number of rows pulled by the importer.Take method. Any suggestions would be appreciated.
I faced the same issue on some files and after analyzing the problem, this is what worked for me.
importer.Take<SnowExcelFormat>(0) have three parameters and one of them is maxErrorRows. Its default value is 10.
Your parsing stop when facing more than 10 errors then the function stop reading.
What you have to do is to set maxErrorRows instead of taking default value that is 10.
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 a question relating to the differences between the 32 bit and 64 bit versions of Excel and VBA.
I am working in Office 365, 64 bit. (I am using 64 bit because I ran into memory issues and as a test, to see if 64 bit works for our company). I am working on an Excel file which has a lot of VBA code used to gather product properties from SQL, calculate parameters from these properties, and output everything to another SQL database. In addition, the Excel file outputs PDF files.
The Excel file is stored as a template, so that users can open the template and save the new file to their respective workspace. At the moment, the users are using Office 365, 32 bit.
When I open the Excel template, Excel closes itself. It seems to crash before calculating the parameters on the new file. There is no error message; in the lower-right message box I can see that Excel doesn't get to the calculating stage.
However, when the other users open the file in 32-bit Excel, everything is fine.
I am not using pointers (no PtrSafe) and no LongLong variables.
I also have no compile errors.
I am currently rebuilding the Excel file by saving it as a file without macro's, and then copying the VBA modules - a different site mentioned the VBA code may be corrupt. I am halfway through adding macro's, and the error pops up again; the VBA code I have added last has been in use for about a year so I am tempted to exclude it as a culprit.
Where would you suggest I look to find the problem?
You're absolutely right of course. I have gone back to the last working version and began adding a text logfile, which would log the start and end of each procedure. I got lucky as the file crashed as I was doing this, and the logfile pointed me towards a procedure seemed to be working, until the right conditions were met for it to crash.
The procedure itself accesses global variables which were not initialised. I didn't catch errors that could occur properly. For some reason, this works fine in x86 Excel, doesn't trigger any problems in the compiler or during debugging but crashes in x64 Excel when enough memory is used.
Gekozen_Assen is the name of a global variable. It is a dictionary which contains information. I had tried to use .Exists as a method to test if the required item in the dictionary exists, but this doesn't work if the dictionary isn't initialized at all.
The errorous code:
GetFromGlobal = ""
If Global_Dictionary.Exists(Answer_Type) Then
GetFromGlobal = Global_Dictionary.Item(Answer_Type)
Else
GetFromGlobal = "Error!"
End If
Instead I should've been using "Is Nothing", the fixed code below:
If Global_Dictionary Is Nothing Then
GetFromGlobal = "Error: Dictionary not initialized"
Else
If Global_Dictionary.Exists(Answer_Type) Then
GetFromGlobal = Global_Dictionary.Item(Answer_Type)
Else
GetFromGlobal = "Error: Dictionary item not found"
End If
End If
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.
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..