The server log gives this error:

"incorrect version or format".

I'm using q&A version 5.0 (DOS)

Thanks,
Steve

The server log gives this error:

"incorrect version or format".

I'm using q&A version 5.0 (DOS)

Thanks,
Steve

The following works with QA DOS 4.0

vnum=@xlu(F:\qatest\stk5.dtf",item,"stk#",list)

I think that there might be a typo here?
Quote:
could not work.  Looks like a missing double quote at beginning, like:
vnum=@xlu("F:\qatest\stk5.dtf",item,"stk#",list)

The following works for me as normal @XLU:

Quote:


But these lines for List and ListAll both come back with blank values:
Quote:
I think the syntax for the paths is correct, but think that perhaps there is some other error.

I am using WriteLn to see results.  I guess the good news is that they are not generating any error messages

AAArgh!  NO!

My Q&A file now says it is not a  Q&A database.

WARNING TO ALL......DO NOT TRY TO DUPLICATE WITH A GOOD Q&A DATABASE !

I better have a backup......this was a critical file.

Sorry about that! Good thing you got a backup!

I'll wait to hear from Lanticans before I go any further on this one.

Steve

I think this problem of corrupting Q&A files should have its own "sticky" subject at the top of the forum discussions.  This is not a problem of a function not working, but a problem of corrupting a file in another application.  Once the problem is repaired, it could be removed as a sticky.

This should also be sent to Tom Marcellus for inclusion in next issue of Inside Sesame.
===========================
Quote:
Obviously that is the best solution for all.

But if any of the "X" family commands will not work with Q&A, I think that something must be done with Sesame to prevent damaging the Q&A file if someone forgets a particular command cannot be used.  Commmand processor needs to look at source database for ".dtf" extension and abort the process immediately, before it tries to open the file and corrupts it.

I don't want to get into discussion about if the Q&A file is "corrupted" or the header is modified.  End result is the user cannot use the Q&A database, and tech support of some nature will be required to repair it.  And if the cause is not known, then it will only repeat itself.

And thanks for info to repair the header.  As it happened, I had already used my backup copy to replace the damaged one.  But the instructions will go into the toolbox for future use (hopefully, never needed).
============================
Whispering:I have known of other software companies who do not admit problems until they have a patch available (which probably needs its own patch).  We certainly don't expect that from Lantica.  Lantica will tell us up front about problems that can be created even if a solution is not readily available.

A note about this will be added to the workarounds page. I will make sure that the documentation gets updated.

As to your advice on how to fix this. It isn't nearly so simple. We use centralized routines to access external databases. These routines are used by all of the "X Commands" and thus cannot differentiate the files by extension. Additionally, it is good practice to minimize the use of file extensions to differentiate file types, especially since we support OSs that do not necessarily use them outside of the HTML browser. So, in place, we use the file header embedded in the .db, .dat, .dsr. ddt files and the file name to match file types.

The bug itself was quite specific to the handful of commands that were added to extend XLookup, in that XLookup itself does not close a an open database until it is certain there will be no further XLookups. When you continued to call XLookupSourceListAll after it had returned a failure, it failed to mark that while that database file was open it had not successfully loaded.

The bug is now fixed. As I mentioned in my last post, the fix will be in the next release.

As a workaround, do not use the commands listed above on Q&A files. If you do, please make sure that you check both the @error (every time!) and check the log file for problems before you deploy on any data that you cannot easily replace. If an @error does occur, do not continue calling any of the extended "X Commands".

If you can't help yourself and do mess up a Q&A file. The repair for that file is trivial and outlined above. I only mentioned the fix because you described your file as "critical" and I wanted to make sure you understood that the file was easily recoverable and that there has been no loss of data or structure.

Quote:


The list at the top is specifically labelled as those X commands which did not exist in Q&A. As XPost and XPostR did exist in Q&A, they are not on that particular list. The list at the bottom lists all the X commands and which type of file they support regardless of where they originated. 

Quote:

No, because they do not work with Q&A. Only those X commands that read were ever supported for Q&A files. XPost and XPostR write, and were never supported. See page 124 of the Programming Guide.

Quote:

Both are correct.

I can accept that, my problem, could have used an @error with message box.  But can you provide any guidelines about using that?  Certaily impractical to use it after every line of code.

I can see using it after every "X" type of command.
I can see using it after  every shell/macro commands.
I can see using it after  every I/O commands with files.

What about sub routines?. Do we use @error at the beginning or end of a subroutine, or pick and choose particular  lines within the subroutine? 
How about array processing?  Loops?

Can we use a generic error trapping routine on any Form Event to handle all code on that form?

Hoping you can provide some guidelines about what types of commands are more likely to generate messages?