the Sesame server engine just crashed (while a Sesame client was executing a 'print' button), and here is the entry in the s2_log0000.log

"16:56:53I$k2S_COM 510091Communications error with socket set notice.`|2012/05/29  15:18:56I$k2S_COM 510091Communications error with socket set notice 2.`|2012/05/29  15:23:30I$k2S_ENGLogging start of server...`

Please advise.

one of the client workstations was attempting to print to a network printer.  The Sesame server engine on the server stopped completely, and Microsoft Windows displayed its "this program has stopped unexpectedly; press 'send report' to notify Microsoft of this problem, blah blah blah".  When these crashes happen (and it isn't specific to just one workstation), it is 'often' when someone is printing something.

One of the first things my Print command button code does is to use CreateAProcess to 'set' the printer to use for that print routine (some buttons 'set' the color printer for sales orders; some 'set' the Label printer for delivery or inventory labels, etc).  I have an 'internal housekeeping Client record' that we use to designate some universal things like printers (previous solution was:  for example, our network 'sales order printer' is named wcOrderL on all of our workstations.  But if that printer has a temporary problem and we can't print to it, then to print orders I have to either 1) go into Sesame Designer and name another printer in the code, then get everyone out of Sesame, then reconcile - and then reverse that process when the wcOrderL printer become functional again;   or   2)  go into every workstation and rename a different printer (the wcInvoic printer, for example) to be 'wcOrderL' so that Sesame code will print to the correct printer.   A big, cumbersome pain - and a real problem if I'm physically not in the office (my staff is many things, but technically savvy/adept is not among those many attributes).   The benefit of the solution I came up with is that now, if we want to redirect a certain print function to a different printer, we just pull up client record 1000, and change the name of the printer in the OrderPrinter field, then save the client record, and all print routines will now read this newly inserted printer name and use it to print orders.   No fuss, no muss.

Here is the print code - am I doing something idiotic that is just not reasonable?  Should I have a longer Loiter for the 'workstation wishing to print' to allow more time to make the 'default printer designation' ?  Should I add code that 'checks to see if vPrinterOrders is not "" before allowing the rest of the code to run?

  vPrint = 0
  vRS1 = @XResultSetSearch(@FN, "Client", SEARCH_MODE_AND, SEARCH_SYNTAX_QA, "!ClientID=" + "1000")
  If vRS1 > -1
    {
      If @XResultSetLocked(vRS1) = 1
     {
       vPrint = 1
      
        }
         else If @XResultSetLocked(vRS1) = 0
           {
                 
             If @XresultSetTotal(vRS1) = 1                        // if there is exactly one matching record in Client, and it's #1000
                 {
                 vPrint = 0
                  vPrinterLabels = @XResultSetValue(vRS1, "PrinterLabels")
                  vPrinterInternal = @XResultSetValue(vRS1, "PrinterInternal")
                  vPrinterOrders = @XResultSetValue(vRS1, "PrinterOrders")
                  vPrinterInvoices = @XResultSetValue(vRS1, "PrinterInvoices")
                 }
           }
    }
     
  XResultSetClose(vRS1)

If vPrint = 1
  {
    @MsgBox("Printer definition table is locked.","Please try again in a second.","")
  }
    else if vPrint = 0

           { // this "{" allows the remainder of code to run

             CreateAProcess("RUNDLL32 PRINTUI.DLL,PrintUIEntry /y /n " + vPrinterOrders)
             Loiter(1000)

Something I just stumbled on is:

I use @CreateAProcess("make a different printer the default printer")  and then a @Loiter command to give the workstation time to 'set' the new default printer.

What I have found is that AlternateDefaultPrinter() works great (and is probably a heck of a lot faster than CreateAProcess) but it will only work with NewDocument() and NewPage.  AlternateDefaultPrinter() will not work with @PrintAForm.  @PrintAForm ignores AlternateDefaultPrinter() and only prints to the default printer. 

Mark,  the above is just a snippet of the entire print code (which is quite lengthy) that I thought was the relevant part.  The crash happened when a user tried to reprint a sales order.  The code worked its way down at least to a @AskUserQuestion() point, but crashed before the code reached the actual "vPrt = @PrintAForm(0, 1, 1, 0, 28, -1, -1, -1, -1, 1, 1)"  command.

When you say you need the whole application, do you mean 'the entire code of that print button', or 'the entire application suite of databases' ?

OK, I can do that.  I recently (several months) upgraded to 2.5.2, and the crashing problem seems to be more frequent than it was with ver 2.5.0. 

Shall I zip the app and send to customer service 'as is'?  Or shall I delete all of the data first (to make the file size much more manageable), then add back in enough data records so that you can operate different daily functions enough to see what's going on?
       In other words, does it make a difference to you if there are a LOT of records that Sesame might need to sift/search through during the course of executing its code, or is it irrelevant if it's 1000 records versus 4 records (and the time difference Sesame would wait to acquire the info it needed)?

ok, I'll do it.  Thanks, Ray.

Looks like I will need your include files as well.

I may need both the one on the server (less likely) and the one on the client (much more likely). I need to be able to compile and run your SBasic code. As is, it does not compile because there are undefined constructs in the code that I assume are defined by changes to an included file or an additional include file.

Sorry, no need. I was testing on Linux. Linux is case-sensitive and you made your include statements all in caps.