I am having some trouble with the following statement:

GL DESC = @XLookup("GLCOA.DB", GL ACCOUNT, "GLCOA!GL ACCOUNT", "GL DESC")      

The programming is attached to an element called GL DESC, on element entry,  in my Vendors app.  It is trying to retrieve this value from the GLCOA app based on a match of GL ACCOUNT in both apps.  The elements above have the same element names and type.

When I click on the GL DESC in Vendors, nothing happens.  However, I noticed that it has kept the GLCOA app open behind the scenes as I tried to reconcile this app and can't because it indicates it is open.  I am the only user of this app currently.

Both apps are in the same directory on the same server session in C:\Sesame\Accounting.

Thanks,

Louis

No luck.  Thanks for the input anyway.

Louis

Erika:

I remembered in the programming course that they do not work in preview mode and have reconciled application with the programming.

We are running client server.  Is this relevant to describing the path of GLCOA ?

Thanks,

Louis

Ray:

I updated the Xuser in both of the databases and it worked. 

I wasn't aware of what this did in the security manager even though I did notice it before.

The write Ln now displays the results and the Xlookup works fine !

Thanks again,

Louis

P.S.  I should attend that designing Sesame course !

Hello Louis,

Any application that gets loaded by an X commands stays loaded, so that future X commands do not have to reload it.

In order to reconcile you need to shut down the Sesame Server.

Server admin, on the client, is not going to reflect it being open as there is no way for it to reflect that it is open. The already being served error is going to be written to the server log.

Whatever you do, Do not unlock any DB file that is shown as loaded on the Sesame Server. Unless you want to risk permanently destroying your DB and DAT files.

-Ray

Quote:

Sesame does not leave files "open". It only opens files while loading and while writing. Because writing is typically very brief, that leaves only a very small susceptability to "write failure" - those cases where an open file is left incomplete due to sudden OS or hardware failure. An open file is (in Windows) left, to some degree, "cached" in RAM. There may be a lengthy period between a write operation and the "flushing" of the cache - if a file is left open. Sesame keeps all of its files closed except while in direct operation on them.

Sesame "compacts" and repairs when the file is loaded, not during operation. That is why your files grow, rather than shrink when you delete records - until the next time you load the file.
Quote:

Yes. But there is an issue that has been addressed in 1.1.3 (soon to be released). You can have two servers. Call them serverA and serverB. If the application "Customers" is loaded on serverA and a client on serverB does an XLookup on that application - it will load on serverB as well as serverA. In that XLookup is a "read only" type operation, that is okay. But because it is now loaded on serverB, a client also on serverB could then open "Customers" and run it without regard for the lock established by serverA. This is problematic. But, as I said, it is resolved in the next release.

Quote:


As long as you upgrade to 1.1.3, it shouldn't be an issue - even with multiple servers.