Everything is set as advised, including mapping of an F drive on the server to the server's own C.  I have "C:\Sesame" set as the Start In for all workstations, Sesame Server, and the Sesame client on the server.

I hard card coded the #include statement to #include "F:\Sesame\Includes\sbasic_include.sbas"" and get no SBASIC failures.

However, my lookups and @Inserts fail.  All the db's and .txt files are in the same directory as the app, and none of the lookup statements or @inserts reference a drive or directory, just the filename.  Hard coding them may solve the problem, but that would be a massive undertaking, and it really shouldn't be necessary, right?

Should Sesame Server have a Start In setting of C:\Sesame\Miara ?

Setting Sesame Server's Start In to C:\Sesame\Miara does not solve the problem  Hard coding a lookup to the exact path\file does.

I have a headache, and it's only Noon.  Usually the throb doesn't set in until 2:30 or so.

Yep.  Did all the above.  Sorry, lookups fail, except the hard coded one which works at my workstation but not when Sesame is run as a client on the server.

Infinity wrote on Jul 13^th, 2007 at 4:10pm:


What directory do the DB files reside in? Same directory as your app means nothing to me, I need the path.

Quote:


Yes copy them to each client and just place them in the C:\Sesame directory.

-Ray

Infinity wrote on Jul 13^th, 2007 at 4:42pm:


hmm then setting the Start In of the Sesame Server to be C:\Sesame\Miara and just referencing the files as "Application.db" should work just fine. The only reason that I can think that it would not work is if the file that is being XLookup'ed is locked. Check that.

Quote:


Or hard code the @Inserts to use the F drive such as  F:\PathToFile\File.txt
That will keep them in a central location.

-Ray

By the way, in regards the lookup failures, the messages in the server log are all of the nature
Quote:


I can open these successfully by themselves; they are not being locked.  One thing to note: when I open MIARA.db and it tries to perform a lookup into, say, Trailers.db, and then I close MIARA.db, MIARA.db disappears from the list of open applications in the server admin window but Trailers.db does not (it appears to stay loaded).  If I do not open MIARA.db but instead just open Trailers.db, do a search, etc, and then close it, it disappears from the window sweet as can be.  I don't know what that means or if it gives any clue to my problem, but I thought I'd mention it.

I tried using my app with the hard coding on another workstation and got compilation errors.  So I have removed the hard coded paths for my #include and @inserts, and will be putting them into each user's Start In folder (currently C:\Sesame for each client).  Once I did that the program compiled nicely.  The only #include file I am using is sbasic_include.sbas.

However, my lookups still fail in runtime.  Hard-coded lookups work in sdesigner preview, however.  That is, in Preview, this will work:

IF NOT @ISBLANK(DESCRIPTION_CODE)
THEN
	{
	DESC_LINE_1 = @XLU("F:\Sesame\Miara\Desccode.db", DESCRIPTION_CODE, "DESCCODE!KEY", "ENTRY_1")
	If @Error then writeln("Lookup failed")
	DESC_LINE_3 = @XLU("F:\Sesame\Miara\Desccode.db", DESCRIPTION_CODE, "DESCCODE!KEY", "ENTRY_2")
	DESC_LINE_9 = @XLU("F:\Sesame\Miara\Desccode.db", DESCRIPTION_CODE, "DESCCODE!KEY", "ENTRY_3")
	} 

But this will not:

IF NOT @ISBLANK(DESCRIPTION_CODE)
THEN
	{
	DESC_LINE_1 = @XLU("Desccode.db", DESCRIPTION_CODE, "DESCCODE!KEY", "ENTRY_1")
	If @Error then writeln("Lookup failed")
	DESC_LINE_3 = @XLU("Desccode.db", DESCRIPTION_CODE, "DESCCODE!KEY", "ENTRY_2")
	DESC_LINE_9 = @XLU("Desccode.db", DESCRIPTION_CODE, "DESCCODE!KEY", "ENTRY_3")
	} 

In spite of the fact that the app making this lookup and the target db both reside in F:\Sesame\Miara\, as seen by my workstation.

Neither of the above work in Runtime.

The only differences in the programs that I can see is that when I start up sdesigner from my workstation, my icon uses the command "C:\Sesame\Program\sdesigner.exe" and when I start Runtime it's "C:\Sesame\Program\sesame.exe -Client Miara-2000serve".  Both have C:\Sesame as a Start In folder.

One other issue I haven't mentioned is that, since migrating my applications to the server, after I reconcile and then try to open my application, the process called "loading" goes very quickly, but then "saving" takes a very long time, upwards of 5 minutes, which is much longer than when it resided on my workstation.  I'm not sure what to make of that.

Since I've been working with a .dsr that came along with the migration to the server, I decided to create a new .dsr using "redesign application" from runtime.  The first two times I tried this it appeared that sdesigner hung, and clicking on the window gave me "this program is not responding".  The third time I decided to wait it out.  It took 10 minutes.

Anyhoo, once I got into the new .dsr, I checked to be sure that the programming was the same as when I was using the old one (it was) and I tried Preview.  This time the hard-coded lookups did not work, nor did (as before) the ones that should just reference the files in the working directory.  So there's clearly a difference in the way sdesigner is seeing my network.  Run from my C drive, sdesigner can see the lookup targets on F.  Run from "redesign this application" it cannot.  In any case, neither db's in hard coded paths nor db's that reside in the same directory as the app are working in Runtime.

Closing my app took 6 minutes.  Saving my new .dsr took 4 minutes.

These things moved like lightning when the files were on my workstation.  It's a Saturday and no one else is here, and mine is the only system attached to the server, so there's no network traffic that might be getting in the way.  As you can imagine, this is all very frustrating, and I'm really at a loss to know what to do next.

I decided to test the copy of my app that I have on my laptop.  These files have never seen a network and I have never used any #include files other than sbasic_include.sbas.

Lookups and @Inserts in Preview work flawlessly.  In Runtime they do not.

These apps worked perfectly up until June 24, the day I installed the programs from the conference disk.

Something is definitely funky, folks, and I'm beginning to suspect it's not me.  Could I have a bad copy of sesame.exe?