ThinkGeo.com    |     Documentation    |     Premium Support

Odd error with layer.ExecuteQuery

On only one machine, I am receiving an error when trying to ExecuteQuery on a SHP file via layer.ExecuteQuery:


Not a valid account name or password.


The permissions on the file are ok. "Everyone" can access the files with full controls. The machine is up-to-date.  I can add the layer for drawing just fine. I can manually connect to a seperate DBF file int he same local directory just fine. The machine is not on a domain but a workgroup named "WORKGROUP". Are there any ideas why this would be happening?



Nelson,  
  
 Just make sure you are running against an x86 Operating system? Because this sql exaction are not supported in x64 OS. 
  
 Besides, can you try to load the shape file in MapSuiteExplorer and execute the sql statement there? If you still have this problem, can you send me your files (.shp , .shx, .dbf) as well as letting me know the sql statement you are testing against? 
  
 Any more questions just let me know. 
  
 Thanks. 
  
 Yale 


Map Suite Explorer is not installed on the culprit production machine. I am wondering when you generate a connection string to connect to DBF within MapSuite component itself, are you using a Username and Password parameter even? I am able to connecto to dbf omitting these. 
  
 The OS is WinXP SP3 x86. The issue is only happening on this test system.

Nelson,


I was wondering this problem is caused by the OLEDB in your production machine. I wrote some codes to do the Sql statement query using OLEDB directly. Please take a try to see it works:

private DataTable ExcuteSqlUsingOledb(string sqlStatement,string shapeFileName)
        {
            DataTable dataTable = new DataTable();
            dataTable.Locale = CultureInfo.InvariantCulture;
            OleDbCommand oleDbCommand = null;
            OleDbDataAdapter adapter = null;

            try
            {
               // sqlStatement = ReplaceTableName(sqlStatement);
                oleDbCommand = GetOleDbCommand(sqlStatement, shapeFileName);

                adapter = new OleDbDataAdapter(oleDbCommand);
                adapter.Fill(dataTable);
            }
            finally
            {
                if (oleDbCommand != null)
                {
                    oleDbCommand.Dispose();
                }
                if (adapter != null) adapter.Dispose();
            }

            return dataTable;
        }

        private OleDbCommand GetOleDbCommand(string sqlStatement,string shapeFileName)
        {
            OleDbConnection connection = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + Path.GetDirectoryName(shapeFileName) + "\\;Extended Properties=dBASE IV;User ID=Admin;Password=");

            if (connection.State != ConnectionState.Open)
            {
                connection.Open();
            }

            return new OleDbCommand(sqlStatement, connection);
        }

For example, when you want to use the Austinstreets.shp(I did not know your shape file name) as example, try passing following example:



DataTable dataTable = ExcuteSqlUsingOledb("Select * from [AUSTIN~1]", @"C:\PostsData\Austinstreets.shp");

Let me know if any more questions have.


 
Thanks.
 
Yale
 

Sorry for the long wait time, Yale. Other tasks and whatnot… 
  
 After using the test you recommended, I generate the same error. It seems you’re onto something. Also, it’s worth noting that this has happened on yet another production PC as well. Where do we go from here?

Nelson, 
  
 I tested against following 2 Operating system with the codes above, and both of them works OK. It seems something wrong with your OS environment: 
  
 OS: Windows 7 Ultimate(Version 6.1.7100 Build 7100) 
 Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM   
 Microsoft .NET Framework Version 3.5 SP1 
 Microsoft Visual Studio 2005 Version 8.0.50727.42 
 Microsoft .NET Framework Version 2.0.50727 SP2 
  
 OS: Windows XP professional Version 2002 Service Pack 3 Build 2600 X86 
 Microsoft Visual Studio 2008 Version 9.0.21022.8 RTM   
 Microsoft .NET Framework Version 3.5 SP1 
 Microsoft Visual Studio 2005 Version 8.0.50727.42 
 Microsoft .NET Framework Version 2.0.50727 SP2 
  
 Can you let us know your OS environment and try to update your OLEDB provider to see this is a fix for this problem? 
  
 Any more questions just let me know. 
  
 Thanks. 
  
 Yale 


I think part of the problem with your test set ups are that they are both development set ups. We are experiencing this on production means without any VS2008 at all, although they do have Access 2003 with one of those machines actually capable of developing in Access 2003.   
  
 Our test machine is highly similar to your XP setup except we do not have a copy of VS 2005 on it. 
  
 Our versions of OLEDB.DLL are the same on systems that throw this error and systems that do not. Our systems are up-to-date with SP3. MDAC is up to date, not that it is really something to be maintained at this point I don’t believe.  
  
 How do you recommend to update the OLEDB.dll driver without taking the MDAC aproach? 
  
 Is there maybe a software utility you are familiar with that can generate a report of installed software and component versions or something along those lines that maybe we could use to compare? I think it’s a very strange issue, but I’m not aware of anything that would affect an MDAC component.

Nelson,


This is really very strange issue I have never encountered before, I DONOT know any software to detect the versions of OLEDB.
 
But it is suggested in WinXP to see its version in Control Panel as shown in below screen shot:
 
 


 
Thanks.
 
Yale

My version is correct, but we think it may be registry keys being set in a script we run during our main application’s installation. When we get it narrowed down I’ll post up what we discovered were culprit so that anyone else who may run into it will have a heads up. Thanks Yale.

Ok, this is the culprit Registry Key that is causing the breaking error as originally described: 
  
 HKLM\Software\Microsoft\Jet\4.0\Engines 
  
 They is is SystemDB 
  
 It is changed from ‘system.mdb’ to ‘c:…\GeoTMS.mdw’. which is for our Flagship database application. 
  
 We severly need a work around for this. The whole purpose of our map viewer is to integrate into our database… We cannot leave SystemDB as system.mdb. 
  
 Thanks. 


Ok, so using the provided code you submitted for testing OLE, if we use our Access credentials into user and password, we are able to connect it seems without the error. This makes lots of sense now!!! My question is can Map Suite offer parameters to set User and Password before or during ExecuteQuery so that we can form the connection string without having to simulate the function ourselves? We would just like to keep code as neat as possible.  
  
 Thanks.

Nelson,


Thanks for your sharing on your progress! Unfortunately, there is no way to input user and password for ExcutingQuery up to now.
 
Can you try to add the user name and password to see it works based on the code I pasted in previous reply.
 
You can change the following line of code by setting correct user Id and password to see it works:

OleDbConnection connection = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + Path.GetDirectoryName(shapeFileName) + "\\;Extended Properties=dBASE IV;User ID=Admin;Password=");

If it works, we will consider adding an overloads for ExcuteQuery or public out the OLEDB connection string to fix this problem.


Any more questions just let me know.
 
Thanks.
 
Yale

That is what I meant to say in my last post, Yale. Sorry that I wasn’t clear enough. 
  
 Yes, by using your code with the credentials we are using for our Access development, we were able to connect just fine. The error originates from pointing the registry key to a new file, which we must do, which has it’s own password And user system and so we break your default behavior of assuming Admin with no password will work. 
  
  I need to know if this will be integrated in otherwise I must scoure my entire project looking for ExecuteQuery so that I can then rip out the code place new code if it turns out Map Suite won’t support this.

Nelson, 
  
 I have submitted this request to my director (Dave), and I will discuss with him about it to see whether we will add this new feature as soon as possible. 
  
 Any feedback will let you know. 
  
 Thanks for your ideas and suggestions. 
  
 Yale 


Nelson, 
  
   I was doing a little research and it seems like we can specify the system database in the connection string.  Could you try to add this as one of the parameter on the connection string sent in the test from Yale? 
  
 Add this: 
 “Jet OLEDB:System Database= system.mdb;” 
  
 It should now look something like this: 
  
 OleDbConnection connection = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + Path.GetDirectoryName(shapeFileName) + "\;Extended Properties=dBASE IV;User ID=Admin;Password=;Jet OLEDB:System Database= system.mdb;"); 
  
 Let’s see how this goes.  If this works we can incorporate it into our internal connection string when connecting to the dbf files. 
  
 David 


Sorry David, 
  
 Hadn’t had a lot of time to check this out since we had a work around involving checking the registry setting. 
  
 Using the connection string “Provider=Microsoft.Jet.OLEDB.4.0;Data Source=” & System.IO.Path.GetDirectoryName(shapeFileName) & “;Extended Properties=dBASE IV;User ID=Admin;Password=;OLEDB:System Database=system.mdb” didn’t work. 
  
 On connection.open, I get the exception “Could not find installable ISAM.”

Nelson,



As far as I know, there are many reasons may cause this issue. Here is an article for you, and it may contains your issue.

support.microsoft.com/kb/318161



Thanks,

Howard



Well, I think what’s actually happening is that Jet is literally looking for a system.mdb as opposed to just reading the registry and if system.mdb is te value to ignore the call altogether. I’m not really sure myself but I’m 100% confident that there isn’t any issues on my machine in regards to this. I think this was just something David wanted me to try so we could see if it would work or not.

Posted By Nelson on 08-18-2009 09:43 AM 

Sorry David, 



Hadn’t had a lot of time to check this out since we had a work around involving checking the registry setting. 



Using the connection string “Provider=Microsoft.Jet.OLEDB.4.0;Data Source=” & System.IO.Path.GetDirectoryName(shapeFileName) & “;Extended Properties=dBASE IV;User ID=Admin;Password=;OLEDB:System Database=system.mdb” didn’t work. 



On connection.open, I get the exception “Could not find installable ISAM.” 



 


Nelson,
 
Sorry for no response for this post threading for a long time!
 
If it still did not work, I am afraid we cannot go around your problem by adding new overloads of ExecuteNonQuery etc.
 
Any more questions feel free to let me know.
 
Thanks.
 
Yale
 



 



I see. Well, it’s a good thing I resolved the issue myself then I suppose…  
  
 Thanks.