Hi -

I'm finally trying to get "back to business," and have encountered a new problem.

I have a locked file so I opened Sesame, selected File, Server Administration. I typed in the Login (admin) and Password (hello) and "Accept" and nothing happens.  Ultimately, I get a  message that "The program is not responding."

The log states:

S_ENG 510600 Default Admin Login
S_ENG Logging Start

Fortunately, this particular locked file is not critical to my needs.  I am very concerned; however, that one of my essential databases could get locked and that I would not be able to unlock it.

Thanks!

Mark -

Bob Hansen was trying to help me with this problem and here is what we did.

1)  First - he uploaded a copy of his program (in case the version of 1.1.3 HF 1 I was using was "corrupted").

That should rule out a problem with the copy of the program itself.

2) We opened the Sesame program using my short cut.  (I was unable to open Server Administration)

He created a new shortcut and the same thing happened.

That should rule out a problem with the short cut itself - although perhaps this distinction provides a "clue".

3)  Using Windows Explorer, we opened Sesame.

Starting Sesame this way, we were able to access Server Administration (which is how I was able to see the log info); however, I was in the C:\Sesame\Program directory and was unable to change it to C:\Sesame\Data (where my programs reside).

He did point out sunlock.exe (which I found in C:\Sesame\Utilities\Lantica); however, when I click on it to execute, I see a "flash" and nothing happens.

I hope this provides sufficient information to identify the cause of the problem.

Thanks!

GEE - IT'S GOOD TO BE "BACK"!

Quote:

Double check the "Start In" setting on the icon's property dialog. Make sure that it is pointing to where your s_conf.cnf file actually resides. Look for additional sesame log files. Are they in the places you would expect?

In general, some setting or directory arrangement must have changed. Possibly a file permission? There are only two thing Sesame does at that juncture: it writes to the log file (check if that has permission) and it reads the licences file. If there is no log file, Sesame will make one. If there is no s_conf.cnf file, Sesame will assume a single user license and default the admin password. But if the log file exists, but for some unknown reason cannot be written to, or if the s_conf.cnf file has been corrupted (you wouldn't believe how many people try to open/edit either file in MSWord!), I suppose there might be trouble.

We have tested here with read only settings and with corrupted files, and have not been able to produce a lock up. But it is impossible to produce exactly identical corruption as might be found in the field

Ray has been investigating a similar sounding problem - on the forum under the thread "Help with Help". We have not been able to reproduce the problem here at all.
Quote:

It is a command line utility and must be provided with the filename (and path) of the application file (.db) that you want to unlock. You cannot run it successfully from explorer - because explorer will not allow you to specify the application filename argument.
Quote:

Its nice to have you back. We, here at Hammer, were all saddened to hear why you were taking a "leave of absence".

Mark -

I read everything posted and I just don't know where to go from here.

I have checked the "Start In" setting on the icon's property dialog and it is set for C:\Sesame (which is where I want it).

I did a search for s_conf.cnf and did not find it; however, since you said Quote:
and since I have a single-user license, I'm assuming the s_conf.cnf file is not needed.

Regarding not being able to change directories, when starting the Server Administration from Windows Explorer, it sounds to me that you are saying that is "expected" behavior.   Since I would not normally start Sesame that way, that is NOT a concern to me.

As for Sunlock.exe - as I had said previously - I was not aware of the utility and I did not read about it.  Thanks to your feedback, I just tried it with the "run" command, specifying the target file and it worked just fine ... so that is a great "stop-gap" solution. 

I would of course prefer being able to run Server Administration in the "normal" (easier to use) way ... so ..... now what?    (Perhaps if you sent me a copy of Sesame 2.0 that would fix the problem!)   roflol

Thanks!

Mark -

KUDOS!

What a simple fix, once you know to use it.  lol  (But, darn, I was still hoping I could connive a copy of version 2.0.  I'll just have to come up with some other plan).

I renamed the log file, started Sesame from my shortcut and accessed the Server Administration successfully - and a new log file was created.

Here's some additional info.

1)  The size of the original (renamed file) is 753 MB, whereas the newly created log file is only 400 KB.  Both reside in C:\Sesame

2)  There are six (6) additional s_log0000.log files in the same directory, ranging in size from 1.23 kb to 13.4 kb.

Are they all needed?

Thanks!

Mark -

You are right about the size of the new file.  What looked like 400 kb was actually 4.00 kb  (hard to see those teeny decimal points at my age).  lol

You are also right that the log files were actually in different directories (something I somehow overlooked, probably because I limited my search to c:\sesame and forgot that it would also include subdirectories of that path).

The original renamed and the new recreated log are in C:\Sesame

The others are in subdirectories (under C:\Sesame) of:

  data
  program
  samples
  utilities
  utilities\Lantica
  utilities\sesame\arcade

Can I still get rid of them?

In any event, I am delighted that everything appears to be working correctly now.

Thanks again!

Quote: Quote:


Another Quote: Quote:


No matter how many layers of GUI MS heaps on top of the OS, Windows is still primarily a command line driven OS (as they all are - really). Because of that, when any command is run, it must have a "current working directory" - which is basically the same as doing a "CD" to that directory before running any particular command.

When Sesame is started with the icon, it looks to the icon's properties to determine the CWD. But when run from explorer, it uses the defaults set for explorer. In each case it looks for its files, including which log file to use, based on the CWD. If it can't find the log file it makes a new one. So if kicked off from the icon, and the icon has the "Start In" set to C:\Sesame\Data, it will look for and use the log file in that directory. If started from explorer, it may have a CWD of C:\, and look for its log file there.

In Spencer's case, the log file existing where the icon's properties put the CWD was corrupt. The log file where explorer put the CWD was either non-existent, or at least - not corrupt. So when Spencer tried to write to the log file using Sesame launched from the icon, he would lock up. When he ran from explorer, he did not.

Quote:


They are both. Remember that Sesame is the same executable, whether run as client, server, or standalone. Both the client and the server can (and will) write to log files. If run standalone, that will be the same file. Of course, if client/server there will be a log file on the server and another on the client.