TOPIC:

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

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

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

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

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

Alf,

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

Jamal

Hello Alf,

Alf wrote: 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

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: github.com/X-Sharp/XSharpPublic/issues/908

Thanks for the report and for looking into it everybody!

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

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

Hi Alf,

Yes, this should be fixed long ago, see github.com/X-Sharp/XSharpPublic/issues/908
If you can confirm it is indeed fixed also in your real environment, it would be great!

.

Hi Chris,
yes, I can conform: It works perfect.
Alf

Great, thanks for your feedback Alf!