Problem with searching for expression on NTX index

[ThomasWYale]

I migrated an application from VO 2.8 to X#, corrected all the runtime exceptions, and everything seems to work exactly as the original VO application, except for just one thing.

The dbf's in my application use DBFNTX driver for its indexes. For one table in particular, it has to search for records in a particular order. Here's a sample of one field in a series of records that are ordered normally:

Dv
Dvs
Dvs 2x- (in a separate field included in the index)
DvsagP

The particular algorithm I have to search this dbf, however, requires the records to be in this order:

DvsagP
Dvs
Dvs 2x-
Dv

To do this, I replaced the trailing spaces after the expressions with "{", which has a higher ASCII value than all other alphabetic characters, and reindex with this field, along with others:

DvsagP{{{{{{
Dvs{{{{{{{{{
Dvs 2x-{{{{{
Dv{{{{{{{{{{

At runtime, SetSoftSeek(TRUE) and SetAnsi(FALSE). SetSoftSeek(TRUE) should set the pointer after a failed search to the next record whose index value is greater than that of the search value. Executing DBSeek(<cExpression>+"{") in VO works just fine, but the corresponding X# application can't find the record and sets the pointer at EOF(). Does the driver for X# disregard non-alphanumeric characters in dbf fields?

[Chris]

Hi Thomas,

It should work the same way in X# as in VO. Can you please post a zip with the dbf and ntx files so we can have a look?

.

[ThomasWYale]

Sure. Wow, you replied quickly.

The index orders are as follows:

DBUSEAREA(FALSE,"DBFNTX","c:DiscoverydbfsTYPERULE.dbf")
DBCREATEINDEX("c:DiscoverydbfsTYPERUL1","TYP+Rule+Placehlder")
DBCREATEINDEX("c:DiscoverydbfsTYPERUL2","TYP+StrZero(SUBTYPE,2)+Rule+Placehlder")
DBCREATEINDEX("c:DiscoverydbfsTYPERUL3","StrZero(BASETYPE,3)+TYP+StrZero(SUBTYPE,2)+Rule+Placehlder")

[ThomasWYale]

One other thing that might be helpful: it's the only dbf that uses StrZero() in the index expression.

[ThomasWYale]

Quick update. At runtime, when I open up the indexes in sequence, it leaves the order to 3 when it should be 1. Once the indexes are open, I execute SetOrder(1) and it seems to work fine. The only other problem that appears is when the application searches for expressions in the other two indexes using StrZero(), which may be significant. In that case, it generates a runtime exception.

Code: Select all

Description :	Conversion Error from USUAL (LONGINT)  to STRING
Subsystem :	BASE
GenCode :	EG_DATATYPE Data type error
FuncSym :	USUAL => STRING
Severity :	ES_ERROR
Can Default :	False
Can Retry :	False
Can Substitute :	False
Argument Number :	1
Argument :	USUAL
Arguments :	{0}
Expected Argument Type :	System.String
Stack Trace :	
 __USUAL:OP_IMPLICIT (Line: 0)
 TBALLTYPES:ADDLISTVIEWITEMDR (Line: 1029)
 TBALLTYPES:LISTVIEWMOUSEBUTTONDOWN (Line: 1958)
 WINDOW:CONTROLNOTIFY (Line: 0)
 WINDOW:DISPATCH (Line: 0)
 __WCDIALOGPROC (Line: 0)
 CALLWINDOWPROC (Line: 0)
 __WCCONTROLPROC (Line: 0)
 ISDIALOGMESSAGE (Line: 0)
 APP:EXEC (Line: 0)
 DIALOGWINDOW:EXECMODAL (Line: 0)
 DIALOGWINDOW:SHOWMODAL (Line: 0)
 DIALOGWINDOW:SHOW (Line: 0)
 PERMUTATIONEXPLORER:BTNGRAMMARRULEEDIT (Line: 233)
 RUNTIMEMETHODHANDLE:INVOKEMETHOD (Line: 0)
 RUNTIMEMETHODINFO:UNSAFEINVOKEINTERNAL (Line: 0)
 RUNTIMEMETHODINFO:INVOKE (Line: 0)
 OOPHELPERS:SENDHELPER (Line: 0)
 OOPHELPERS:SENDHELPER (Line: 0)
 OOPHELPERS:DOSEND (Line: 0)
 SEND (Line: 0)
 WINDOW:__COMMANDFROMEVENT (Line: 0)
 RUNTIMEMETHODHANDLE:INVOKEMETHOD (Line: 0)
 RUNTIMEMETHODINFO:UNSAFEINVOKEINTERNAL (Line: 0)
 RUNTIMEMETHODINFO:INVOKE (Line: 0)
 OOPHELPERS:SENDHELPER (Line: 0)
 OOPHELPERS:SENDHELPER (Line: 0)
 OOPHELPERS:DOSEND (Line: 0)
 __FORMFRAME:__COMMANDFROMEVENT (Line: 0)
 RUNTIMEMETHODHANDLE:INVOKEMETHOD (Line: 0)
 RUNTIMEMETHODINFO:UNSAFEINVOKEINTERNAL (Line: 0)
 RUNTIMEMETHODINFO:INVOKE (Line: 0)
 OOPHELPERS:SENDHELPER (Line: 0)
 OOPHELPERS:SENDHELPER (Line: 0)
 OOPHELPERS:DOSEND (Line: 0)
 __FORMDIALOGWINDOW:__COMMANDFROMEVENT (Line: 0)
 WINDOW:DISPATCH (Line: 0)
 __WCDIALOGPROC (Line: 0)
 CALLWINDOWPROC (Line: 0)
 __WCCONTROLPROC (Line: 0)
 ISDIALOGMESSAGE (Line: 0)
 APP:EXEC (Line: 0)
 XAPP:START (Line: 1850)
 START (Line: 149)

Other than that, there is some input that doesn't complete processing, but that appears to be a separate problem altogether that I can solve.

[Chris]

Hi Thomas,

Yeah, it was a lucky moment, I happened to check emails right at the moment you sent yours

Thanks for the files, that always helps! But I could not see the problem you describe, I seem to get the same behavior in X# as in VO. Please note that the indexes you provide use composite expressions, in none of which the field you mentioned earlier is the first one. I think i have not completely understood the problem you are describing, so could you please also post a small (compileable) sample showing the problem (difference to VO)? Also please include some code that also shows the runtime error you are getting.

TIA!

.

[ThomasWYale]

I'm sorry for the confusion. The earlier problem with looking up expressions was due to the application setting the index order to 3 when it opened up the last of 3 index files:

Code: Select all

*TypeRule analysis
DBUSEAREA(TRUE,"DBFNTX","c:DiscoverydbfsTYPERULE.dbf")
DbSetIndex("c:DiscoverydbfsTYPERUL1") // index key "TYP+Rule+Placehlder"
DbSetIndex("c:DiscoverydbfsTYPERUL2") // "TYP+StrZero(SUBTYPE,2)+Rule+Placehlder"
DbSetIndex("c:DiscoverydbfsTYPERUL3") // "StrZero(BASETYPE,3)+TYP+StrZero(SUBTYPE,2)+Rule+Placehlder"

Immediately after the last line I inserted

Code: Select all

DbSetOrder(1)

which is supposed to be the default, otherwise it would search for expressions with the wrong index, which it did. After that, I no longer had the problem. But the section of code which generated the runtime exception was here, while another window was open, at the line indicated:

Code: Select all

METHOD addListViewItemDR 
LOCAL oLVI AS ListViewItem
oLVI:=ListViewItem{}
oLVI:SetText(Trim(ObjForm),#OBJFORM)
IF oMainWindow:nSelectedMode=3
 oLVI:SetText(Oem2Ansi(Trim(ExampleSen)),#EXAMPLESEN)
ELSE
 oLVI:SetText(Trim(ExampleSen),#EXAMPLESEN)
ENDIF
oLVI:SetText(Trim(Result),#RESULT)  // <<<<<<<<<<<<<<<<<<<< this one
oLVI:SetText(Trim(DefConstrn),#DEFCONSTRN)
oLVI:SetText(Trim(Primary1),#PRIMARY1)
oLVI:SetText(Trim(Primary2),#PRIMARY2)
oLVI:SetText(Trim(Primary3),#PRIMARY3)
oLVI:SetText(Trim(Primary4),#PRIMARY4)
oLVI:SetText(NTrim(RecNo()),#RECORD)
SELF:oDClvDefRule:AddItem(oLVI)
RETURN NIL

In which case it doesn't seem to have resulted from any problem with the index key with the composite expression StrZero(). You were exactly right that this should behave the same way in X# as in VO. I apologize for that oversight. Instead, the problem looks as if the word RESULT is reserved in X# but not in VO. I looked the word up in X# Help and Result is the name of a field for DbLockInfo and DbOrderInfo. Whether this is actually a conflict, I don't know. I have, however, encountered this conflict between fieldnames and reserved words in a number of places, for example, the fieldname TYPE in one dbf conflicting with the word TYPE. For those I renamed the fields and all references to the affected fields by other names, after which it compiled okay.

[Chris]

Hi Thomas,

Ah, indeed DbSetIndex() in VO retains the existing active order while X# changes it, I hadn't realized this problem (incompatibility with VO). Thanks for that, will log a bug report for Robert to adjust this.

But unfortunately I still do not have enough information to understand or reproduce the other problem. In the code you showed, there are manyidentifiers like "result", "primary1" etc which I do not know what they represent and from what I see they are not dbf fields. Can you please post a compilable sample that reproduces the problem?

Edit: or maybe it is enough to say what "RESULT" represents in your code. Is it a GLOBAL? A PROTECT in your CLASS declaration? If yes, what type is it defined as?
.

[ThomasWYale]

X# chaing the active order upon opening more than one index was a minor problem, but I'm glad that I was able to contribute to greater compatibility to VO.

As for a compilable sample, that may take some time to put together. The entire application has 88,035 lines of code, 69 forms, opens 98 DBF's, many more NTX's. Also, the window in which it occurs, GrammarRuleEdit, is opened via pushbutton by another Window called oMainWindow. If you wish, I could include the entire application in a ZIP file. I was concerned that it would be too big to send all at once.

To provide more context at least, I included all the code just for for the module Grammar Rule Edit, as well as all the DBF's that the window uses. "Result", "Primary1", et al, referenced in METHOD addListViewItemDR are indeed DBF field names for string fields in the table DEFRULE.dbf. I used the /memvar and /undeclared compiler options to enable the X# version to recognize them as fieldnames.

[Chris]

Hi Thomas,

Ah, OK, got it now! So you are using a different dbf, with a field named RESULT and also using a DIalogWindow in this case, which actually has an ACCESS named Result, so that's where the conflict happens. It's silly, but in VO apparently if there's a PROTECT/EXPORT with the same name as a field (which I had assumed previously that might be happening), then the PROTECT/EXPORT has priority over a same named field. But when you have an ACCESS with the same name, then it's the field that has priority!! In X# they both get priority right now... Argh, does not make sense what VO does I think, but since that's another X# / VO incompatibility, I will log a ticked for it as well.

Till this is adjusted in X#, fortunately there's an easy fix, just change that line where you use RESULT as a dbf field with FIELD->RESULT and it should work fine.

.