client server fails to connect to SLX db using SLX 8.1 OLE DB Provider

[neema]

The client machine has the following installed.

1. SQL Server native client 2008 R2

2. SLX OLE DB Provider (version 8.1)

Our SLX DB is upgraded to 8.1 and resides on our db server.

The datasource is configured on our 8.1 sales Logix server

On the client machine, I uninstalled SLX OLE DB Provider 7.5 and installed SLX OLE DB Provider 8.1 from the "client OLE DB Provider" folder that came as part of the installation.

I am an administrator on the client machine and can successfully connect to the using a 32-bit UDL connection to the SLX db. In this

case I am selecting the SLX OLE DB Provider as the provider.

Other users (including administrators) fail to connect using the UDL connection.

The website on the client machine is running under a different account and hence fails to connect to the  SLX DB.

When I installed the 8.1 SLX OLE DB provider, there was no option to install the provider for all users

The error seen in the log file as below.

System.Data.OleDb.OleDbException: No error message available, result code: E_FAIL(0x80004005).

   at System.Data.OleDb.OleDbConnectionInternal..ctor(OleDbConnectionString constr, OleDbConnection connection)

   at System.Data.OleDb.OleDbConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject)

   at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)

   at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)

   at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)

   at System.Data.OleDb.OleDbConnection.Open()

   at System.Data.Common.DbDataAdapter.QuietOpen(IDbConnection connection, ConnectionState& originalState)

   at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)

   at System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32 startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior behavior)

   at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)

   at EBI.Slx.DB.GetDataAndLog(OleDbCommand cmd) in c:\Vss\SalesLogix\main\SlxLib\DB.cs:line 1547

   at EBI.Slx.DB.UserGetAll() in c:\Vss\SalesLogix\main\SlxLib\DB.cs:line 1270

I read in a post on the forum that for a login to successful this path should exist  which should contain the

SLXProviderExtensions.dll

C:\Windows\SysWOW64\config\systemprofile\AppData\Local\SalesLogix\SLXOLEDB\PluginCache\<SalesLogix server_Initial Catalog name>

The above path does contain the dll file on our dev client server and the website is able to connect to the SLX DB successfully.

Our dev client server had SLX OLE DB provider version 8.0 already installed months back. I did not have to uninstall and reinstall

8.1 version of OLE DB Provider

But our beta machine which currently has the problem does not have the folder 'SalesLogix' under

 the path below

C:\Windows\SysWOW64\config\systemprofile\AppData\Local\

I ran process monitor on our beta client server to see where the connection fails.

It fails because it is not able to find this path

C:\Windows\SysWOW64\config\systemprofile\AppData\Local\SalesLogix\SLXOLEDB\PluginCache\<SalesLogix server_Initial Catalog name> and hence cannot find the SLXProviderExtensions.dll at this path

Why is this path missing on our beta environment?

Any help would be highly appreciated.

[mcessna]

Hi Neema,

The following are a few suggestions:

1. Make sure "Enable 32-Bit Applications" is set to True for the application pool.

2. Make sure that the SLXService user is defined for the connection pool. See step 2 in the Required Tasks section of the Implementation Guide.

3. Note: A UDL will not work by double-clicking on a 64 bit box; I'm not sure how your users are testing the UDL.

4. The stack you provided looks like it might be from an .EXE project? If so, make sure the .EXE targets x86; it cannot target x64 [or] Any CPU because the SLXOLEDB provider is a 32 bit component.

Thanks

Mike

[neema]

Hi Mike,

Thank You for the response.

1.Yes, "Enable 32-Bit Applications" is already enabled in the application pool

2. We are not using the SLXService user.

3. I am testing the UDL connection using the below command

C:\Windows\SysWOW64\rundll32.exe "C:\Program Files (x86)\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile C:\Users\ngudur\Desktop\testudl.udl

[mcessna]

Hi Neema,

The PluginCache location is created by SLXOLEDB; if SLXOLEDB cannot be loaded then that location will not be created. The user defined for the app pool must be able to write to that location. It sounds like a permissions issue for that particular issue.

Regarding the UDL, every user will need to have the SLXOLEDB provider installed on their client machines (assuming they're trying to connect from other machines).

Thanks

Mike

[neema]

Won't SLXOLEDB be loaded when I select the SLX OLE DB Provider to connect via the 32-bit udl connection

[mcessna]

Yes, as long as the SLXOLEDB provider is installed on the same machine where the UDL is run.

Thanks

Mike

[neema]

yes, SLXOLEDB provider is installed on the same machine where the UDL is run.

 I would have tested this  like 20 times. Each time the connection was successful but the 'PluginCache' path was not created.

When I ran the UDL, I was logged in as myself and I had full control to the path.

C:\Windows\SysWOW64\config\systemprofile\AppData\Local

This should have created the plugincache path.

Also, the user did not have access to this path. When I added the user to the group and restarted the SalesLogix System Service, it

still did not work.

I rebooted the machine and it worked.

[mcessna]

Ok. SLXOLEDB always expects the Local AppData location for a user profile to be writable; this is where a couple of DLLs are stored (i.e. SLXProviderExtensions.dll and SLXHistorySecurityExtension.dll) for each data source. Assuming each user has their own profile when they login, SLXOLEDB should be looking under %LocalAppData%\SalesLogix\SLXOLEDB\PluginCache when executing the UDL (where does %LocalAppData%\SalesLogix\SLXOLEDB\PluginCache point to for these users?). It's only when an .EXE (e.g. W3WP.EXE) runs under the system account that the SystemProfile is used. Do you have another way of testing the client connections? Regarding the UDL, please also see: http://community.saleslogix.com/t5/Administration/Can-not-run-SLXProviderPlugin-exe/m-p/160995#M3605...

Thanks

Mike

[neema]

You are absolutely right!

The %LocalAppData% when I log into the machine as myself is C:\Users\ngudur\AppData\Local and the dlls

SLXProviderExtensions.dll and SLXHistorySecurityExtension.dll are stored at this path

C:\Users\ngudur\AppData\Local\SalesLogix\SLXOLEDB\PluginCache .

The service SLXSystem.exe(This is the service for SLXOLEDB, correct?) is running under the SYSTEM account.

But the w3wp.exe is running under the user account  'syncappbeta' and not the 'SYSTEM' account.

The dlls were created under the systemprofile when I used the w3wp.exe process, i.e; I accessed the SLX db via a website ptsslxlink.

Does it mean that since syncappbeta user does not have a userprofile, the dlls were created under the systemprofile?

Thank You so much, I have learnt a lot from your responses.

Very helpful indeed!!