Using HOST app - New problem with opening files in 'sub' sites

[Devan]

Ok, we have been progressing at a turtle pace with the implementation of HOST.EXE to run multiple web servers.

We are up to the stage where when we run 'static' pages from the sub sites, it all seems to work OK, but as soon as we try and go to a page with database access, we get the following GPF:

Code: [Select]

Program : C:\Data\Clarion8\Multi Host\host.Exe
Version :
At : 17:49:32 on 2012/02/29
Workstation: : BLAZE-NB-12
User Name: : Devan
Reported error : EXCEPTION_ACCESS_VIOLATION - Error reading data at : 00000004h
Windows : Win 7   - 6.1.7601 Service Pack 1
Clarion : 0.801
Thread : 3 Field : 0 Event : 0 Keycode : 0
Error at address : 0CBFC7EBh  Line=25  Proc=NETWEBRELATIONMANAGER@FBf  Src=WebOr_nw.clw  Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
Stack Trace
[01] 0CB71FD2h Line=282 Proc=_OPENFILE@F5P_WEBBf  Src=WebOrders001.clw  Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
??? 0CC7D5B0h Line ?=5026 no proc Src=xFiles.clw Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
[02] 0CB5C6E0h Line=2743 Proc=R$VALUE::LOC:SITEGUID  Src=WebOrders001.clw  Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
??? 0CC3007Ch Line ?=5026 no proc Src=xFiles.clw Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
[03] 0CB61EC4h Line=2267 Proc=R$GENERATETAB0  Src=WebOrders001.clw  Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
??? 0CC7D5B0h Line ?=5026 no proc Src=xFiles.clw Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
[04] 0CB636CFh Line=1912 Proc=R$GENERATEFORM  Src=WebOrders001.clw  Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
??? 0CC7D5B0h Line ?=5026 no proc Src=xFiles.clw Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
[05] 0CB6579Eh Line=1544 Proc=LOGINFORM@F18NETWEBSERVERWORKERl  Src=WebOrders001.clw  Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
??? 0CC78928h Line ?=5026 no proc Src=xFiles.clw Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
[06] 0CB724E4h Line=154 Proc=PROCESSTAG@F5P_WEBsb  Src=WebOrders001.clw  Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
??? 0CC6410Ch Line ?=5026 no proc Src=xFiles.clw Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
??? 0CC7D5B0h Line ?=5026 no proc Src=xFiles.clw Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
[07] 0CAF9225h Line=5675 Proc=_HANDLETAG@F18NETWEBSERVERWORKERsbOsb  Src=NetWeb.Clw Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
??? 0CC7D5B0h Line ?=5026 no proc Src=xFiles.clw Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156
[08] 0CAF694Ch Line=6120 Proc=R$MIDDLEBIT Src=NetWeb.Clw Module=C:\Data\Clarion8\WebOrders\WebOrders.dll 0.9.91.156


Is there something we have missed?  We are using the MS-SQL driver on these sites.  In the DLL, under Global Properties -> Actions -> File Control, I have tried ticking and unticking 'Export all file declarations' without any luck.

Cheers,
Devan

[kevin plummer]

Have you copied across the sqldriver dll's to your folder?

Although I'm running MSSQL in a multi dll web app I'm not doing it via HOST.exe so i can't offer any specific help.

[Devan]

Hi Kevin,

Yes, I have copies the MS-SQL DLL into the folders of BOTH the DLL webapp and the host folder.  I have even included the MS-SQL driver in the list of drivers on the host app, even though it doesn't use SQL itself.  No changes.

I even imported an SQL file from the DLL into the host app just to see if that would make a difference, but no.

It's one of those frustrating situations where the answer is probably quite simple, but I have no idea what to try next?!?

Cheers,
Devan

[Bruce]

GPF's are fairly common if the DLL isn't done exactly right - so much so that the Host has a "tab" (Notes) with some things to check.

The most common reasons are;

1. Prototype of WebServer not set correctly (must include Name attribute)

This is the WebServer procedure in the DLL. Check it carefully, as it needs to be set for DLL operation.
WebServer, not WebHandler.
Should be
(<NetWebServer pServer>),name('WebServer')

2. Prototype of WebHandler procedure not set correctly (also include Name attribute)

Ok, so now double check that the WebHandler has the Name attribute on it.
Prototype should be
(String p_String),Name('WebHandler')

Both prototypes are compatible with running the app as an Exe as well, so you can set it like this for both DLL and EXE operation.

3. NetWeb version of DLL and Host app do not match

Make sure you've compiled the Host and DLL with the same build of NetTalk - this is not normally a problem when starting out - more likely to be a problem later on when you start updating DLL's.

Cheers
Bruce

[Devan]

Hi Bruce,

Yep, I checked off all the above.  Both apps have been recompiled using NT 6.21.

As I mentioned before, the app works fine when serving up static pages, but as soon as I go to the login page, or any page that requires database access, bam, it crashes.

Seems to be the 'NetWebRelationManager(p_file) procedure that dies, specifically this line:

  If p_File &= Relate:dborderheader.Me.File then RM &= Relate:dborderheader.

according to the debug log above.

From this I am suspecting it is database driver related?

Cheers,
Devan

[kevin plummer]

try to recompile you app as an exe in local mode and run from the current location of your dll in case it is to do with missing files or the location.

[Devan]

Hi Kevin,

Yeah, I've tried that too... The webapp USED to run fine as an EXE, and I recompiled to a DLL for HOST.EXE but that failed.

I've since recompiled it as an EXE again and run it from it's own folder, PLUS from the HOST folder as a standalone EXE and it works fine.

Something is either not getting exported or linked correctly as a DLL I believe... No idea where to start looking though!! 

Cheers,
Devan

[Bruce]

Devan,

I'm going to update the example (ie MultiHost app) for today's build (6.23) - it's not been tweaked to NT6 styles etc yet. I'll check everything's working ok there - so that'll give you either a reference, or indeed a fix.

cheers
Bruce