Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 10 total
Thread DBISAM ODBC 11010 Error on Remote Workstation
Tue, May 11 2010 3:09 PMPermanent Link

Hanson

I have an [classic] ASP application that accesses data from a remote server using a third-party supplied DBISAM ODBC driver (sorry, I don't know what the proper DBISAM version of the driver is on this third-party usage).  I use a DSN reference within my ASP pages.  The DBISAM files reside on a Windows 2003 SBS, while my ASP website runs on a Windows 2008 x64 Web Server (under IIS7).

The problem that I'm having is that I can run the ASP pages just fine on my 2008 server -- accessing the data residing on my 2003 SBS; however, when I attempt to run the same ASP pages on a network workstation, I receive a 500 error.  Having traced the IIS tasks, I see the following:

<System>
 <Provider Name="ASP" Guid="{06B94D9A-B15E-456E-A4EF-37C984A2CB4B}"/>
 <EventID>0</EventID>
 <Version>1</Version>
 <Level>5</Level>
 <Opcode>54</Opcode>
 <Keywords>0x0</Keywords>
 <TimeCreated SystemTime="2010-05-11T18:27:16.115Z"/>
 <Correlation ActivityID="{00000000-0000-0000-D505-0080000000FC}"/>
 <Execution ProcessID="4112" ThreadID="3168"/>
 <Computer>SERVERA</Computer>
</System>
<EventData>
 <Data Name="ContextId">{00000000-0000-0000-D505-0080000000FC}</Data>
 <Data Name="FilePath">C:\INETPUB\WWWROOT\LUNCHESV2\MYSQLTEST.ASP</Data>
 <Data Name="LineNumber">34</Data>
 <Data Name="CurrentStatement">adoRS.open strQuery</Data>
 <Data Name="SizeOfStatement">19</Data>
</EventData>
<RenderingInfo Culture="en-US">
 <Opcode>ASP_SCRIPT_TRACE_COM_CALL_START</Opcode>
</RenderingInfo>
<ExtendedTracingInfo xmlns="" name="http://schemas.microsoft.com/win/2004/08/events/trace">">http://schemas.microsoft.com/win/2004/08/events/trace">
 <EventGuid>{1FC299FA-3FC4-4C37-910D-DE5B911D0270}</EventGuid>
</ExtendedTracingInfo>
</Event>
<Event xmlns="" name="http://schemas.microsoft.com/win/2004/08/events/event">">http://schemas.microsoft.com/win/2004/08/events/event">
<System>
 <Provider Name="ASP" Guid="{06B94D9A-B15E-456E-A4EF-37C984A2CB4B}"/>
 <EventID>0</EventID>
 <Version>1</Version>
 <Level>5</Level>
 <Opcode>55</Opcode>
 <Keywords>0x0</Keywords>
 <TimeCreated SystemTime="2010-05-11T18:27:16.131Z"/>
 <Correlation ActivityID="{00000000-0000-0000-D505-0080000000FC}"/>
 <Execution ProcessID="4112" ThreadID="3168"/>
 <Computer>SERVERA</Computer>
</System>
<EventData>
 <Data Name="ContextId">{00000000-0000-0000-D505-0080000000FC}</Data>
 <Data Name="FilePath">C:\INETPUB\WWWROOT\LUNCHESV2\MYSQLTEST.ASP</Data>
 <Data Name="LineNumber">34</Data>
 <Data Name="CurrentStatement">adoRS.open strQuery</Data>
 <Data Name="SizeOfStatement">19</Data>
</EventData>
<RenderingInfo Culture="en-US">
 <Opcode>ASP_SCRIPT_TRACE_COM_CALL_END</Opcode>
</RenderingInfo>
<ExtendedTracingInfo xmlns="" name="http://schemas.microsoft.com/win/2004/08/events/trace">">http://schemas.microsoft.com/win/2004/08/events/trace">
 <EventGuid>{1FC299FA-3FC4-4C37-910D-DE5B911D0270}</EventGuid>
</ExtendedTracingInfo>
</Event>
<Event xmlns="" name="http://schemas.microsoft.com/win/2004/08/events/event">">http://schemas.microsoft.com/win/2004/08/events/event">
<System>
 <Provider Name="ASP" Guid="{06B94D9A-B15E-456E-A4EF-37C984A2CB4B}"/>
 <EventID>0</EventID>
 <Version>1</Version>
 <Level>2</Level>
 <Opcode>60</Opcode>
 <Keywords>0x0</Keywords>
 <TimeCreated SystemTime="2010-05-11T18:27:16.131Z"/>
 <Correlation ActivityID="{00000000-0000-0000-D505-0080000000FC}"/>
 <Execution ProcessID="4112" ThreadID="3168"/>
 <Computer>SERVERA</Computer>
</System>
<EventData>
 <Data Name="ContextId">{00000000-0000-0000-D505-0080000000FC}</Data>
 <Data Name="LineNumber">34</Data>
 <Data Name="ErrorCode">80004005</Data>
 <Data Name="Description">[Elevate Software][DBISAM] DBISAM Engine Error # 11010 Table or backup file &apos;TGrdLvl&apos; does not exist</Data>
</EventData>
<RenderingInfo Culture="en-US">
 <Opcode>ASP_LOG_ERROR</Opcode>
</RenderingInfo>
<ExtendedTracingInfo xmlns="" name="http://schemas.microsoft.com/win/2004/08/events/trace">">http://schemas.microsoft.com/win/2004/08/events/trace">
 <EventGuid>{1FC299FA-3FC4-4C37-910D-DE5B911D0270}</EventGuid>
</ExtendedTracingInfo>
</Event>

I've done a lot of research on the IIS website and tripled checked my Authentication settings.  I'm using Windows Authentication with Kernal-mode enabled.  I had to configure it this way in order for the site to work on the server itself.

I've set permissons on the actual data directory (on the remote server) to allow NETWORK SERVICE and IUSR_SERVERA rights to the data, plus setting the DBISAM ODBC temp directory with the same user rights.

I can run ODBCTest on SERVERA using the DBISAM ODBC driver configuration and all works fine as well.  Everything points to this being a permissions issue, yet I can't seem to figure out what user the ODBC driver is referencing in order for me to set the proper permissions on the remote server.  I even tried setting Everyone on the data directory, but that didn't work either.

(I should mention that I enabled 32-bit support on the Application Pool, but this should be implied since the ASP pages work fine on the x64 2008 Web Server itself.)

Any suggestions on what additional troubleshooting steps I can take?
Thu, May 13 2010 2:27 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Hanson,

<< The problem that I'm having is that I can run the ASP pages just fine on
my 2008 server -- accessing the data residing on my 2003 SBS; however, when
I attempt to run the same ASP pages on a network workstation, I receive a
500 error.  Having traced the IIS tasks, I see the following: >>

When you say "run the same ASP pages on a network workstation", do you mean
that you're running the ASP pages using the local IIS installation on the
workstation ?  If so, is the local DSN or connection string that you're
using referring to the proper location on the 2003 SBS Server ?

If so, then download the the Database System Utility here:

http://www.elevatesoft.com/download?category=dbisam

as part of the DBISAM Additional Software and Utilities.  You should try
DBISAM 4.x first, and then you can go with a earlier version if DBISAM 4.x
doesn't work correctly with your database tables.

After installing the above download on one of the network workstations,
launch the Database System Utility from the Programs menu, and then try to
use File/Open Table to browse to the 2003 SBS Server directory where the
database tables are located and open up one of the tables.  If it works,
then there's definitely an issue with the DSN location or permissions of the
IIS user account being used with the ASP web pages.

See here for more information on fixing a permissions issue:

http://support.microsoft.com/kb/207671

under "Problem Avoidance".

--
Tim Young
Elevate Software
www.elevatesoft.com
Thu, May 13 2010 10:41 PMPermanent Link

Hanson

Thanks for the reply and sorry for not being more clear in my description.  What I meant by stating that I'm running the same ASP pages on a remote workstation is that on my x64 2008 server, I type in the URL, http://localhost:81/mytest.asp and it works fine.  On my workstation, I type in the URL, http://SERVERA:81/mytest.asp and it doesn't work.  In this particular example, I'm on the 2003 server typing in http://SERVERA:81/mytest.asp.  I'm logged on as the Administrator user on the 2003 server when trying to run the ASP page, so I know I have proper rights to read/write to the DBISAM data directory, yet I still receive the "500" error with the details being that the table does not exist.

In the third-party ODBC configuration, I don't have an option to set a username, so does this mean that I can't use a DSN on my x64 bit server?  I don't have the problem running similar ASPs on my 2003 server from remote workstations, which implies that there's something unique about IIS7 and/or the 32-bit ODBC driver running under the 64-bit 2008 server -- even though I have 32-bit Application support enabled.

Any other suggestions that I can try?

"Tim Young [Elevate Software]" wrote:

Hanson,

<< The problem that I'm having is that I can run the ASP pages just fine on
my 2008 server -- accessing the data residing on my 2003 SBS; however, when
I attempt to run the same ASP pages on a network workstation, I receive a
500 error.  Having traced the IIS tasks, I see the following: >>

When you say "run the same ASP pages on a network workstation", do you mean
that you're running the ASP pages using the local IIS installation on the
workstation ?  If so, is the local DSN or connection string that you're
using referring to the proper location on the 2003 SBS Server ?

If so, then download the the Database System Utility here:

http://www.elevatesoft.com/download?category=dbisam

as part of the DBISAM Additional Software and Utilities.  You should try
DBISAM 4.x first, and then you can go with a earlier version if DBISAM 4.x
doesn't work correctly with your database tables.

After installing the above download on one of the network workstations,
launch the Database System Utility from the Programs menu, and then try to
use File/Open Table to browse to the 2003 SBS Server directory where the
database tables are located and open up one of the tables.  If it works,
then there's definitely an issue with the DSN location or permissions of the
IIS user account being used with the ASP web pages.

See here for more information on fixing a permissions issue:

http://support.microsoft.com/kb/207671

under "Problem Avoidance".

--
Tim Young
Elevate Software
www.elevatesoft.com
Mon, May 17 2010 4:09 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Hanson,

<< Thanks for the reply and sorry for not being more clear in my
description.  What I meant by stating that I'm running the same ASP pages on
a remote workstation is that on my x64 2008 server, I type in the URL,
http://localhost:81/mytest.asp and it works fine.  On my workstation, I type
in the URL, http://SERVERA:81/mytest.asp and it doesn't work.  In this
particular example, I'm on the 2003 server typing in
http://SERVERA:81/mytest.asp.  I'm logged on as the Administrator user on
the 2003 server when trying to run the ASP page, so I know I have proper
rights to read/write to the DBISAM data directory, yet I still receive the
"500" error with the details being that the table does not exist. >>

I'm sorry, but I don't understand any of that.  Could you give me a rundown
of the steps you're taking, including on which machine you're executing the
request, and on which machine the ASP pages are actually being served up via
IIS.  I suspect that the issue is with the DSN on the machine that is
hosting the ASP pages, but I need to get straight how many machines are
actually hosting the ASP pages.

<< In the third-party ODBC configuration, I don't have an option to set a
username, so does this mean that I can't use a DSN on my x64 bit server? >>

Which username are you referring to ?  My understanding is that you're not
using the DBISAM Database Server, therefore a user name isn't necessary at
all.

<< I don't have the problem running similar ASPs on my 2003 server from
remote workstations, which implies that there's something unique about IIS7
and/or the 32-bit ODBC driver running under the 64-bit 2008 server -- even
though I have 32-bit Application support enabled. >>

Wait a minute - I thought you said in your original message:

"I should mention that I enabled 32-bit support on the Application Pool, but
this should be implied since the ASP pages work fine on the x64 2008 Web
Server itself."

So, now you're saying that the ASP pages *don't* work on the 2008 server ?

--
Tim Young
Elevate Software
www.elevatesoft.com
Tue, May 18 2010 11:56 PMPermanent Link

Hanson

Let's see if I can explain things this way:

My 2003 SBS server is where my DBISAM files are located in a shareable directory.  This server is also where my original website is running.  The website is using an ODBC driver that my ASP is referencing with a DSN.  I have no issues with remote workstations running the ASP site from this server.

Recently, I purchased a 2008 WebServer x64 with the intent of offloading all of my company's intranet sites to free up resources on my 2003 SBS.  I simply want to keep my 2003 server as a file server where my DBISAM, MySQL, and other database files reside.  Therefore, I copied the ASP website that references the DBISAM files from my 2003 SBS server to this 2008 server and am in the process of configuration it to work like it did on my 2003 server.  I installed the same DBISAM ODBC driver that was installed on the 2003 server.  Instead of pointing to the C:\DBISAM\Data like on my 2003 server, the directory entry is pointing to the shared drive (e.g. T:\Data).  I know my ODBC driver is configured correctly as I've run ODBCTest on the 2008 server referencing the DSN that I configured and I can perform SELECT clauses and get data back.  I've configured the ASP website's ApplicationPool to support 32-bit.  I've also set the Authentication to be Windows Authentication.  After doing this, I can successfully run the ASP website on the actual 2008 server.  I do this by logging on to the 2008 server as Administrator, opening up a browser window and navigating to http://localhost:81/mytest.asp.  

The problem that I have is when I log onto a network workstation.  I can log into a network workstation as Administrator, open up a browser and navigate to http://SERVERA:81/mytest.asp, but receive a 500 error.

So, to answer your question:

  ...including on which machine you're executing the request, and on which machine the ASP pages are actually being served up via IIS.

  I'm executing the request on two machines -- one is the 2008 server (aka SERVERA) and on a workstation.  IIS7 is configured on SERVERA.  The ASP pages are being served up via SERVERA.  When executing the ASP from SERVERA's browser it works fine.  When executing the ASP from the workstation a 500 error is returned.

I'm not sure how else to explain the situation any clearer; however, I'm attaching a BMP to reflect my environment setup.

- Dave

"Tim Young [Elevate Software]" wrote:

Hanson,

<< Thanks for the reply and sorry for not being more clear in my
description.  What I meant by stating that I'm running the same ASP pages on
a remote workstation is that on my x64 2008 server, I type in the URL,
http://localhost:81/mytest.asp and it works fine.  On my workstation, I type
in the URL, http://SERVERA:81/mytest.asp and it doesn't work.  In this
particular example, I'm on the 2003 server typing in
http://SERVERA:81/mytest.asp.  I'm logged on as the Administrator user on
the 2003 server when trying to run the ASP page, so I know I have proper
rights to read/write to the DBISAM data directory, yet I still receive the
"500" error with the details being that the table does not exist. >>

I'm sorry, but I don't understand any of that.  Could you give me a rundown
of the steps you're taking, including on which machine you're executing the
request, and on which machine the ASP pages are actually being served up via
IIS.  I suspect that the issue is with the DSN on the machine that is
hosting the ASP pages, but I need to get straight how many machines are
actually hosting the ASP pages.

<< In the third-party ODBC configuration, I don't have an option to set a
username, so does this mean that I can't use a DSN on my x64 bit server? >>

Which username are you referring to ?  My understanding is that you're not
using the DBISAM Database Server, therefore a user name isn't necessary at
all.

<< I don't have the problem running similar ASPs on my 2003 server from
remote workstations, which implies that there's something unique about IIS7
and/or the 32-bit ODBC driver running under the 64-bit 2008 server -- even
though I have 32-bit Application support enabled. >>

Wait a minute - I thought you said in your original message:

"I should mention that I enabled 32-bit support on the Application Pool, but
this should be implied since the ASP pages work fine on the x64 2008 Web
Server itself."

So, now you're saying that the ASP pages *don't* work on the 2008 server ?

--
Tim Young
Elevate Software
www.elevatesoft.com



Attachments: DBISAM.bmp
Wed, May 19 2010 6:53 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Hanson,

<< Recently, I purchased a 2008 WebServer x64 with the intent of offloading
all of my company's intranet sites to free up resources on my 2003 SBS.  I
simply want to keep my 2003 server as a file server where my DBISAM, MySQL,
and other database files reside.  Therefore, I copied the ASP website that
references the DBISAM files from my 2003 SBS server to this 2008 server and
am in the process of configuration it to work like it did on my 2003 server.
I installed the same DBISAM ODBC driver that was installed on the 2003
server.  Instead of pointing to the C:\DBISAM\Data like on my 2003 server,
the directory entry is pointing to the shared drive (e.g. T:\Data).  I know
my ODBC driver is configured correctly as I've run ODBCTest on the 2008
server referencing the DSN that I configured and I can perform SELECT
clauses and get data back.  I've configured the ASP website's
ApplicationPool to support 32-bit.  I've also set the Authentication to be
Windows Authentication.  After doing this, I can successfully run the ASP
website on the actual 2008 server.  I do this by logging on to the 2008
server as Administrator, opening up a browser window and navigating to
http://localhost:81/mytest.asp.

The problem that I have is when I log onto a network workstation.  I can log
into a network workstation as Administrator, open up a browser and navigate
to http://SERVERA:81/mytest.asp, but receive a 500 error. >>

Ahh, okay, now I've got it.  The problem definitely sounds like what you
suspected - it's the use of the Windows authentication for the incoming ASP
users that is probably responsible for the disparity in the results between
the Administrator and the normal network users.  Did you try switching the
ASP authentication method to something that would allow both to use the same
user account for the ASP application ?  That should tell you for sure if
that is the issue or not.

--
Tim Young
Elevate Software
www.elevatesoft.com


Wed, May 19 2010 10:20 AMPermanent Link

Raul

Team Elevate Team Elevate

<< Instead of pointing to the C:\DBISAM\Data like on my 2003 server, the directory entry is pointing to the shared drive (e.g. T:\Data).  >>

This might not be the source but doing it this way is not advisable - mapped drives are user sessions specific in most cases so it might work only work if you access it using account that mapped the drive (e.g. local admin).
Using UNC (e.g. \\ServerSBS\MyDBisamShare ) would the way way to go normally.

Also ensure permissions are OK for IIS account accessing the remote share as Tim suggested.

Raul
Wed, May 19 2010 10:45 PMPermanent Link

Hanson

Thanks, guys, for your recommendations.  I turned off Windows Authentication and re-enabled Basic Authentication.  I specified the user name to be the associated IUSR_SERVERA user, restarted everything, but still had the problem with the "500" error on remote workstations.  I then changed the user account to Administrator, restarted everything and it all worked.  So, very long story short, it's definitely the user.  I just now have to figure out what user I can appropriately use, but at least I now know where I can concentrate on making future changes.

Thanks for all your help and recommendations.

Sincerely,

Dave

Raul wrote:

<< Instead of pointing to the C:\DBISAM\Data like on my 2003 server, the directory entry is pointing to the shared drive (e.g. T:\Data).  >>

This might not be the source but doing it this way is not advisable - mapped drives are user sessions specific in most cases so it might work only work if you access it using account that mapped the drive (e.g. local admin).
Using UNC (e.g. \\ServerSBS\MyDBisamShare ) would the way way to go normally.

Also ensure permissions are OK for IIS account accessing the remote share as Tim suggested.

Raul
Wed, May 19 2010 10:54 PMPermanent Link

Hanson

Sorry, I forgot to mention that I also had to implement the \\ServerSBS\MyDbisamShare directory as well within my ODBC DSN.

Thanks again!

- Dave

Hanson wrote:

Thanks, guys, for your recommendations.  I turned off Windows Authentication and re-enabled Basic Authentication.  I specified the user name to be the associated IUSR_SERVERA user, restarted everything, but still had the problem with the "500" error on remote workstations.  I then changed the user account to Administrator, restarted everything and it all worked.  So, very long story short, it's definitely the user.  I just now have to figure out what user I can appropriately use, but at least I now know where I can concentrate on making future changes.

Thanks for all your help and recommendations.

Sincerely,

Dave

Raul wrote:

<< Instead of pointing to the C:\DBISAM\Data like on my 2003 server, the directory entry is pointing to the shared drive (e.g. T:\Data).  >>

This might not be the source but doing it this way is not advisable - mapped drives are user sessions specific in most cases so it might work only work if you access it using account that mapped the drive (e.g. local admin).
Using UNC (e.g. \\ServerSBS\MyDBisamShare ) would the way way to go normally.

Also ensure permissions are OK for IIS account accessing the remote share as Tim suggested.

Raul
Thu, May 20 2010 11:51 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Hanson,

<< Thanks, guys, for your recommendations.  I turned off Windows
Authentication and re-enabled Basic Authentication.  I specified the user
name to be the associated IUSR_SERVERA user, restarted everything, but still
had the problem with the "500" error on remote workstations.  I then changed
the user account to Administrator, restarted everything and it all worked.
So, very long story short, it's definitely the user.  I just now have to
figure out what user I can appropriately use, but at least I now know where
I can concentrate on making future changes. >>

The ShellRunas utility may help diagnose this further:

http://technet.microsoft.com/en-us/sysinternals/cc300361.aspx

You can also use the Windows command-line runas utility (didn't know about
this until I did some searching today Smiley.

--
Tim Young
Elevate Software
www.elevatesoft.com
Image