Runtime Error: Wrong field specification, why?

[Alf]

Hi to all,
some of my users (only few) get a runtime error "wrong field specification" when a simple FIELDGET() is executed on a DBF. Mostly this happens when the field type is LOGIC. But I am sure: the field type is really correct (of course I checked this!). When I let me send this specific DBF and test it on one or all of my machines: No error, no problem. Very strange!
Thanks for any help!
Alf

[robert]

Alf,
What is the name of the field?
Could it be that the field has the same name as a property (access) of the server class ?
For example, "Status", "Name" ?

Robert

[Alf]

Robert,
I guess, this can't be the reason. The field names are very specific, like "KLR", "STRFREI21".
May be incorrect installation? To find out this, now I let me send the content of the program directory.
By the way: In the start method of all my appls I call a function which test all DBF structures and all field properties (name, type, length) and compare them with my data dictionary. This function does no detect any inconsistency on the concerning
users machine.
Alf

[Jamal]

Alf,

I suggest you check if the DBF alias or dbServer is the correct one that you are doing the FIELDGET() on.

One way to find out is to override the FIELDGET method and trap the error to return the Alias; that way you can tell for sure what alias or workarea is being used, then trace your code to find out where the issue is coming from.


Jamal

[Alf]

Robert and Jamal,
now I found the reason for my troubles.
In VO: When I set "Setdefault(...)", the DBFs always will be opened (respectively created) in this default directory, so I never have to complement a path to the DBF name.
In XSharp: When I set "Setdefault(...)", the DBFs will be opened (respectively created) in this default directory only, if there exists no DBF with the same name in the program directory.
The behavior in XSharp seems to be different to VO (?).
The disadvantage is: If the user copies or moves DBFs in the program directory (for some unknown reason), I get a real problem. Ok, I can complement GetDefault() in any USE- or CREATE-Statement, but this seems to be a little laborious and dangerous. I'm meditating for a better solution.
Alf

[Jamal]

Alf,

How about also , in addition to SetDefault(), calling SetPath() to point to the same folder?

Jamal

[ic2]

Hello Alf,

The disadvantage is: If the user copies or moves DBFs in the program directory (for some unknown reason), I get a real problem. Ok, I can complement GetDefault() in any USE- or CREATE-Statement, but this seems to be a little laborious and dangerous. I'm meditating for a better solution.

I would say that if you have users who move dbf files they have a problem, not you. There is no solution for stupidness.

We open every dbf using a global cDataPath which is assigned in settings. But if someone decides to move dbf files that won't work either.

Dick

[Chris]

Guys,

Since the behavior is indeed different in X# than in VO (I have confirmed that) and it's not something in the framework preventing X# to have the same behavior with VO, then this is considered a bug. I have opened a ticket for it: https://github.com/X-Sharp/XSharpPublic/issues/908

Thanks for the report and for looking into it everybody!

[Alf]

Chris, Jamal, Dick,
thanks to all for answers.
@Dick: You are right, but everything the users can do wrong, they do it (my experience in 25 years software development).
@Jamal: Good idea, but does not work in my test.
@Chris: For the moment, I added a function in all my start methods, which looks for DBFs (and CDXs) in the program directory and moves them in a dummy directory.
Alf

[Alf]

Chris,
is this "bug" - if I may call it so - solved in 2.12.2.0? I didn't test it yet
Regards Alf