xsharp.eu

Hi,

We use a DBF file with an attribute named "REF" which is a primary key.
This file is used with applications developed under VO 2.7b. This does not pose any problem.
However, when migrating to XSharp, knowing that "REF" is a keyword, it no longer works.

Is there a solution, without modifying the DBF file, to get around this problem?

Thanks.

That should work also in X#. What is the code that you use that gives you problems?

Here is an example of code that does not work:

[STAThread];
FUNCTION Start() AS INT
LOCAL oXApp AS XApp
TRY
oXApp := XApp{}
oXApp:Start()
CATCH oException AS Exception
ErrorDialog(oException)
END TRY
RETURN 0

CLASS XApp INHERIT App
METHOD Start()

TestDBFNTX()

SELF:Exec()

END CLASS
FUNCTION TestDBFNTX()
LOCAL oDB AS DBserver
LOCAL ii AS DWORD
LOCAL sIndex AS STRING
LOCAL cpt AS DWORD

oDB := DBserver{"c:\temp\tests\dodo.dbf", FALSE, FALSE, "DBFNTX"}
IF !oDB:used
TextBox{ , "Error", "open error : "+sIndex}:Show()
ELSE
cpt := 0
FOR ii:=1 TO 20
sIndex := "c:\temp\tests\dodo"+PadL(AllTrim(Str(ii, 2, 0)), 2, "0")+".ntx"
IF !oDB:CreateIndex(sIndex, "REF")
TextBox{ , "Error", "Index create error : "+sIndex}:Show()
ELSE
cpt ++
ENDIF
NEXT ii
oDB:Close()
TextBox{ , "Information", AsString(cpt)}:Show()
ENDIF
RETURN



The problem occurs when the index was created with VO and when using DBserver:SetIndex in XSharp.

Thanks, I see the problem, so it happens when creating an index. It's a bug, will open a report about this for it to be fixed, but fortunately there's a workaround you can use, change

oDB:CreateIndex(sIndex, "REF")

to

oDB:CreateIndex(sIndex, "@@REF")

and it should work. The "@@" in front of a keyword name tells the compiler (and the macrocompiler here, which is used to compile the index expression) to not treat the keyword as such, but as a regular identifier instead.

it works in XSharp.
However, the new index "@@REF" is no longer readable by VO. Too bad.
thanks for your feedback.

Ah, right, sorry about that. Are you a FOX subscriber? If yes, I will send you a fix as soon as this is fixed.

No, I am not a FOX subscriber

That's fine of course, I think the problem will have been fixed until the release of the next public build and will be included in there. Unless it proves very difficult to fix it (it's a problem in the macro compiler and might be a bit complicated), but I don't expect so.

Link to the reported issue, so you can monitor its progress: https://github.com/X-Sharp/XSharpPublic/issues/1557