A couple of times in the last year and a half, the following scenario has played out:     the Sesame server crashes (with the Windows notice to the screen that "sesame.exe has crashed and will be closed - do you want to send a report to Microsoft about this error?"), but the Sesame clients continue to look and act normal, so users are inputting data for a while until finally someone's Sesame client gets 'kicked out', and we investigate and discover the Sesame server crash.   Well, when I "unlock" the database and restart the server, all of our input data from earlier in the day is gone (or at least back to the last backup earlier in the day (orders that got created and printed and saved somehow don't 'stick', and are lost upon reboot of the server).

My knee jerk suspicion is always that Windows is to blame.  Is this a Windows issue?  Or has the Sesame server gotten 'glitched' for some reason (probably my programming somewhere having a random hiccup) and become hobbled but not immediately disabled?  Either way, 'Is there a way for me to program code so that the Sesame server notifies Sesame clients immediately when Sesame server performance becomes degraded?

Hi Ray,

I'll grab it with gotomypc tonight ("yea! gotomypc") and send it.  Thank you.

File has now been sent.

Ray,

I'll ask around today.

I do know that I have a 'toggle tableview' command button in my POLines that will quite often cause a sesame error box and tone to pop up.  It usually repeats 3 times, then stops.  It's a button that I originally programmed 3 years at the beginning of my learning curve, and had a complicated string of 'make this list of fields invisible if tableview' and 'that list of fields invisible if formview'.  I never could get it to work just right, but what I didn't realize was how often one of my users used that button.  So I guess she was constantly causing sesame errors to popup on her client machine.  I have since disabled that button and provided an alternative method for her to see a realtime listing of line items.   It may have no bearing on this server crash issue, but in case it could ...

Bharat,

That's a good suggestion - I'll check my code.

I suppose a little background on what you are probably seeing:

Sesame client / server works by having the client issue a command to the server. The server then does that command and replies to the client. The client will wait for that reply. So, if you have clients that are still issuing commands, the server hasn't crashed.

I'm guessing that Ray figures that for some reason (anit-virus, backup, or other system wide program) is wandering by and telling the OS to lock your Sesame application files on the server. The server can still receive and reply to commands, but can't save the results to the application files - even though it is changing that application in memory. Eventually, being unable to write out changes, or for some unrelated reason, the server goes down.

Ray, am-I-right?

Hi Ray,

I will try to get to the server over the weekend and get the info you requested.

I wonder if the following 'aside' could have something to do with this issue - for quite a while now, intermittently we would have a user working in PO's, and be unable to make changes to a PO because Sesame said it was 'locked',  but no one else would be in PO's at all.  The only way to unlock the PO was to go exit the Sesame client on a computer in the warehouse that we use to 'receive' incoming inventory.  It's an older computer running XP.  I finally got irritated enough about it to replace it with a newer computer, but the intermittent problem would still occur.  For an unrelated reason, I just this week replaced that newer computer with yet another computer.   And lo and behold, we had another 'record is locked' occur while posting/printing a batch of invoices in Sesame (and that computer has nothing to do with invoicing or order screens.    As I've had 3 computers in that slot, but the problem doesn't go away, it's obviously not a 'specific pc' problem.  So Thursday, thinking perhaps the network cable (which sounds nuts, but not too long ago I had a malfuncting computer on a different node that was making me crazy because I could not pin down the ghost.  I tried everything, and finally discovered that the network cable had somehow 'gone bad' - once I replaced the cable, she was running like the wind) or the network switch on that node was malfunctioning, I bypassed the existing ethernet cable and connected that network node via a different cable route.  I've got my eye on it for the next week or two to see if the problem is resolved, or will continue to vex me.   

But your description of what was happening (Sesame couldn't write to .db, and a crashed thread had a record 'locked') got me to wondering if perhaps the two issues are  really one and the same?  Could my possibly defective network cable be causing the server crash as well as the intermittent phantom 'locked record' ?

Ray,

I'll investigate that. 

I am clueless about how to locate the windows application log you have requested I send you.

lksseven wrote on Apr 10^th, 2012 at 4:47am:


It could be that it's not omitted but that it doesn't run. I have seen similar to the following before

vRS = @XResultSetSearch(@Fn, "Customers", 0, 2, "Key=" + Key)
If vRS >= 0 Then
{
	If @XResultSetTotal(vRS) = 1 Then
	{
		XResultSetClose(vRS)
	}
	Else
	{
		@MsgBox("Either no Customer Record or Multiple Customer Records found", "Please refine your search","")
	}
} 

There is an XResultSetClose() BUT it only runs if there was only 1 record found. So if it found two records, the resultset is not closed so the first record will be marked as locked.

-Ray