Vulcan runtime, DBFCDX order seek failure on customers machine

[wriedmann]

Hello,

I have a problem with a VO compatible application that uses the Vulcan runtime (I need DBFCDX).
On my machine a seek works as expected, and on my customers machine the seek fails.
The files are the same (I have copied them over from the customers machine), and I have made sure that I have copied all Vulcan runtime DLLs to the customers machine.
And yes, I'm using SetCollation( #Clipper ), and SetInternational( #Clipper ).

Any ideas?

Wolfgang

[Karl-Heinz]

Hi Wolfgang,

are there differences in the "Seek ()" and "Found" results ?

if oDB:seek ( ...)
? "found"

else
? "not found"

endif

// --------------

oDB:seek ( ... )

if oDB:Found
? "found"

else
? "not found"

endif


regards
Karl-Heinz

[wriedmann]

Hi Karl-Heinz,

on the customers machine the following code

Code: Select all

oServer 	:= DBServer{ cPath, true, false, "DBFCDX" }
System.Console.WriteLine( "SetOrder(" + cOrder + ") returns " + AsString( oServer:SetOrder( cOrder ) ) )
System.Console.WriteLine( "Seek(" + cSeek + ") returns " + AsString( oServer:Seek( cSeek, true ) ) )
System.Console.WriteLine( "EOF returns " + AsString( oServer:EOF ) )
System.Console.WriteLine( "Kdnr is " + AsString( oServer:FieldGet( #Kdnr ) ) )

returns

Code: Select all

Hello x#!
SetOrder(KDNR) returns .F.
Seek(MOSER) returns .F.
EOF returns .F.
Kdnr is 0001

On my machine instead it returns

Code: Select all

Hello x#!
SetOrder(KDNR) returns .T.
Seek(MOSER) returns .T.
EOF returns .F.
Kdnr is MOSER

Wolfgang

[wriedmann]

Hello,

yes, and the application is using the VO dialect, so the InitVulcan() call should not be needed.

On my machine, Vulcan is installed, so I have all DLLs in the GAC. But I have triple checked if all DLLs that the application loads on my machine are installed also on the customers machine.

Is there any setting put when Vulcan is installed?

Wolfgang

[wriedmann]

Hi Karl-Heinz,

the customers machine is a WIndows Server 2012 foundation.

I have now copied the following two files into the program folder:
msvcp100.dll
msvcr100.dll

and now it works as expected.

It seems that these DLLs are available on Windows 10, but not on Server 2012 or Windows 8.x.

Wolfgang

[Karl-Heinz]

Hi Wolfgang,

> Hello x#!
> SetOrder(KDNR) returns .F.
> Seek(MOSER) returns .F.
> EOF returns .F.
> Kdnr is 0001

so already SetOrder() fails.

> I have now copied the following two files into the program folder:
> msvcp100.dll
> msvcr100.dll

Seems that some Visual C ++ Redistributable Package is missing, so I would not simply copy the DLLs to another PC. i do have both Dlls in my win 8.1 system32 and syswow64 dir, all have the datestamp 11.06.2011

Strange, that at runtime no errorbox like "xxxx.dll is missing" is shown.

regards
Karl-Heinz

[robert]

Karl-Heinz, Wolfgang,

The DbServer class "swallows" all the errors. After a failed SetIndex(), SetOrder() etc, you need to check the dbServer:Status. This most likely has a hyperlabel with a message describing the problem. You need to do that immediately. Every operation can/may reset the status.
This is a "built-in" problem of the VO classes. I think this is designed badly but we can't change that anymore: A failed operation should not return FALSE but generate an error/exception. People quite often forget to check the return value of an operation and almost never check the status of the Server object.

Robert

[wriedmann]

Hi Robert,

thank you for this explanation!

Wolfgang

[g.bunzel@domonet.de]

Robert,

>This is a "built-in" problem of the VO classes. I think this is designed badly but we can't change that anymore

I check all return values of every SetOrder(), SetRelation(), ....
Is that return value a problem of the Vulcan runtime or will this also be a problem in the X# runtime?
I would not be pleased to have to change all these checks to status.

Thanks in advance

Best regards

Gerhard

[Chris]

Hi Gerhard,

No, no, in both vulcan and x# it works like in VO, you still get a TRUE/FALSE return value (success yes/no) from those functions/methods and dbServer:Status can be used the same way.

Robert was suggesting that it would had been better if the SDK classes were designed from the beginnning in such a way to throw exceptions when something failed (because for example if a Skip() fails, then it very rarely makes sense to execute the next commands of the code after it), but of course we will not be making such major changes to the SDK now, as that would indeed break a lot of existing code as you pointed out.

Chris