Interesting problem calling VFP7 DLL from a classic ASP Page

[chriscboy]

Hi All,

I have an interesting/wierd problem with a DLL that was written using VFP7. In a nutshell the DLL I have written queries a VFP database and returns the results as an ADO recordset. This DLL is then used in a classic ASP page to display the results returned to our CRM system.

Now all this was working fine on my development system, but once I moved it to our live environment it stopped working. Lots of debugging later and what 'appears' to be happening is that the DLL is ignoring the USE statement and SET DATABASE TO statements. I confirmed this by raising an error using the following Error command to see what was happening.

ERROR "Alias = "+ALIAS()+" USE NEW WORKAREA5 "+This.TableName+" "+SET("Database")

Here ALIAS() or SET("Database") returns a blank string, and because of this I get a "No table is open in the current work area" error when I start querying the VFP database.

Now what makes this all the more bizarre, is that if I use the same code to call the DLL from a Visual FoxPro program, or a VBA excel macro, in the live environment it all works fine!!

I tried re-compiling and installing the DLL and tried an IIS reset to no avail. I'm going to reboot the server tonight to see if that makes a difference.

I am stuggling to work out what exactly is going on here, if anyone has any ideas that would be great as I am fast running out of ideas!!

Chris

 

[TamarGranor]

I'm wondering if you're actually erroring on opening the database and/or table. Does your DLL have an error handler built in?

Is the database or table open elsewhere? If so, have you made sure that both places SET EXCLUSIVE OFF or open things SHARED?

Tamar

 

[chriscboy]

Hi,

Thanks for the reply.

I have an in built error handler which stores the error info in some properties, so I know if an error has occured. The Database is opened shared but I have noticed I don't have a SET EXCLUSIVE OFF when setting my environment up. However the tables are opened shared.

The tables being accessed are being used by other users on the network, although if attempts are made to open the tables exclusively I would hope the error handler would kick in.

I will try including a SET EXCLUSIVE OFF to see if that makes a difference.

 

[Mike Lewis]

Chris,

Keep in mind that, if your DLL class is based on a Session class, the setting for EXCLUSIVE changed in VFP 7.0. If I remember right, it now defaults to ON in a session class (but I'm not completely sure).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro tips, advice, training, consultancy
Custom software for your business

 

[TamarGranor]

If you're issuing USE SHARED, then SET EXCLUSIVE shouldn't make a difference. But maybe SHARED is missing somewhere.

Tamar

 

[Imaginecorp]

I would try passing the path to the table and database to the DLL as a parameter as you are already passing it the table name...
I could be totally wrong here, but it’s working in the development mode and from a VFP program, because it inherits the path...
What’s throwing me off is how is it finding the tables with a VB Excel macro?

 

[Olaf Doschke]

Imaginecorp,

if you have a database opened, then a use tablename will lookup the path to the table in the dbc. Of course you need to open the dbc with the full path to it.

As you get an empty SET('DATABASE'), does the open database fail? Do you not open the database from the COM object? Do you open it with a wrong path? Have you tried SET DATABASE TO ...?

Bye, Olaf.

 

[chriscboy]

Right problem found. It turns out it was a permissions issue as when I was calling the DLL from the ASP page I was running under the IUSR account, whereas when I was calling the DLL from a VFP program/VBA Macro I would have been under my Admin account.

Giving the IUSR account read rights to the database has fixed the issue but I still don't understand why I didn't get an error such as File access denied etc...

Thanks for all your suggestions.