Could not use ”; file already in use.”

System.Data.OleDb.OleDbException occurred
  ErrorCode=-2147467259
  Message=”Could not use ”; file already in use.”
  Source=”Microsoft JET Database Engine”

Access, lock files, and Visual Source Safe – an accident waiting to happen! I got the above error, after my code had been fine for weeks. Googling turned up permissions on the folder with the Access database, and closing secondary applications. The solution in the end turned out to be that the .ldb file had come under source control. Removing it from this, and deleting the fle resolved the issue.

Advertisement

Operation must use an Updateable Query

I know I see this error about once a year and can never remember the cause, so I’m writing it down this time!

In my case it has always been related to SQL queries and Access databases. Check the following if your SQL command produces this error when executed:

1. The database is not read only – Visual Source Safe can often be a culprit in setting this property..
2. The SQL query may contain fields that are reserve words (e.g. DATE, TOP etc.). These should all be renamed in the database (I normally add an underscore at the end).
3. Go through a long and tedious process of which Windows user is running the SQL (ASPNET, IUSR_COMPUTERNAME etc.) and check thy have write permissions to the folder containing the database, and the database file itself. Remember Access needs to create those pesky .ldb lock files..

MS Access and Application.ExportXML

Just spent a few hours bieng frustated by the error message “reserved error 2950” when trying to export a query from MS Access 2002.

Turns out the problem was with one of the field names being “Size”, once renamed everything ran without problems. I guess this could apply to all reserved words.

No New Objects Added…

 If only Visual Studio would open in the same state that it was closed..

Excluded DLLs in set up packages seem to re-include themselves, projects in solutions disappear, and today an ArcObects command seemed to have disappeared.

All had previously been running without problems in debugging mode, opening ArcMap and then stopping at various breakpoints. However today no breakpoints were hit. Not even on the OnCreate or New functions of the BaseCommand. The button in ArcMap had disappeared. Adding it manually from the .tlb gave the “No New Objects Added” message.

Some time later after much blood, sweat, (and possibly tears), I delved into the registry. I searched for the class ID in key values and names. The class ID can be found in the class code file of the tool:

Public ConstClassId As String = “480d624c-3d4c-4210-ae11-0c775dddc35d”

Then I took the rather risky step of deleting all these keys. If anyone does the same I’d recommend making a backup of the registry first – not that I did myself..
Anyway I think the class must have been registered twice, or there was an error in the registry, as the next time I started the project with debugging everything had started working again =)

Project Build Error

Error messages always seem to make far more sense when you know the solution.

System.IO.FileNotFoundException was unhandled
  Message=”Could not load file or assembly ‘GISSettings, Version=1.0.0.17923, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The system cannot find the file specified.”

This error occurred when building a deployment project in Visual Studio 2005. The GISSettings was a custom made DLL that was referenced by another custom DLL, and it was definitely still there on my machine…

The cause of this was that the second project was looking for a specific version of the GISSettings DLL which no longer existed. I had automated the version numbers for all my DLLs by using the 1.0.0.* syntax for the Assembly Version in the Assembly information of each project. The solution was as follows:

– Show all the files for the project in Visual Studio
– Expand the References
– Check that the Copy Local Property for the relevant DLL is set to true

I had referenced several other custom DLLs which had this property set to true, so why this one had behaved differently I have no idea..VS 2005 does seem to have a few idiosyncrasies, such as when half my projects in a solution disappear, so I guess I’ll have to wait for a few more service packs before I start blaming myself for these issues =)

Windows Installer Woes

Finally…all the major bugs have ironed out for a new custom ArcMap tool, a “simple” installer package has been created in Visual Studio and emailed to a colleague for testing. I can now turn off the computer happy in the knowledge that the project is thankfully out of my hands for a few days.

First email the next day..it wouldn’t install, there were errors. Specifically:

“Unable to get installer types in the [name of DLL] assembly. –> Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. “

Well I never  did work out how to retrieve the LoaderExceptions property, but after seemingly recreating and installing in an infinite loop I ascertained the following:

i) The DLL I was installing relied on another custom made DLL that had to be installed on the system to even allow the package to run.

ii) On my development machine the latest DLL had been registered as it was part of the same Visual Studio solution.

iii) On the test machine an older version of the DLL was still being used. I believe this lacked a new class I had since added that was in turn required by the new DLL. This had to be removed, and the latest version of this DLL installed.

iv) Hindsight has 20/20 vision…the new DLL and installer package were deployed without problems.

I believe this error also occurs when trying to install a DLL created on a machine with ArcGIS 9.x, on a machine with ArcGIS 8.x. This would be for the same reasons – a class which the custom DLL relies on has been added/modified/removed.

An invaluable tool in the whole install/uninstall process is the “Windows Installer CleanUp Utility”, downloadable from the Microsoft site at http://support.microsoft.com/kb/290301. This is very useful when the control panel’s Add/Remove Programs interface no longer seems to work.

UPDATE

This error has since made a few reappearances, but this time for a different (albeit) similar reason. After several fruitless hours I decided I would make the effort to “Retrieve the LoaderExceptions property for more information.”

There is a useful program named FUSLOGVW.exe. I found this in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\ – it had been installed as part of Visual Studio 2005. This progam logs exceptions for “failed Assembly binds“ – further details can be seen on MSDN here.

I set the program to record all application binds for my installation and set the custom log path to the folder where the .DLLs would be installed:

Just after the error message popped up I hit refresh and was pleasantly suprised to see the log viewer had filled with entries as shown below.

This list included both successful and unsuccessful “binds.” Double clicking on the last entry opened up a browser with further details, including the fact that the “operation” had failed.

The (fairly obvious) clue was in the “system cannot find the file specified” when trying to bind to the ESRI.ArcGIS.ADF.DLL. One of my custom tools was trying to call functions in this file, but could not find it. I had excluded all ESRI DLLs from my setup package as I had assumed they would be on any machine with ArcMap…apparently not! By default the .NET support (basically all the ESRI .NET DLLs) are notinstalled. After modifying the ArcGIS installation from the DVD and adding this option the installation ran without further issues =)

A final point on this issue – I would recommend setting all your custom DLL version numbers manually. To check if this is already the case go to Project >> Properties >> Application >> Assembly Information, and make sure there are no asterisks amongst the version numbers.