This is because VO rounds the size to 1K pages. If you inspect the last 512 bytes of the VO CDX then you'll see that this is empty (or could contain garbage, I am not sure).
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
the first bytes of the last 512 bytes seem to contain garbage, followed by 0s - but the last 4 bytes are "5A 45 41 4C" -> "ZEAL". This is the name of the last person in the created order. The same byte order exists before the last 512 bytes start.
Hallo
As i said, i was goinig back to X#2.6a. The troubles with the ftp files comes also.
Then i saw, 2.10 is now online. I installed this version hopefull it will fix my problem.
But it was more worst. On click and the PRG destroyed the ftp.
The method - Kontroll_Ein_Insert makes a new Tmp File. and -- Kontroll_Edit_Browser cant read the file. The Tmp file is in the zip.
METHOD Kontroll_Ein_Insert (nRecno AS DWORD) AS VOID PASCAL
LOCAL odbServer AS _cryptServer
LOCAL odbServerNew AS _cryptServer
LOCAL cFile AS STRING
LOCAL cTempfile AS STRING
LOCAL nRecno2 AS DWORD
IF ! FErase (String2Psz (cFile))
SELF:WriteCgiLog ("altes File konnte nicht gelöscht werden "+cFile )
SELF:Err_DeleteFile (cFile, "Kontroll_Ein_Insert")
ENDIF
IF ! FErase (String2Psz (StrTran (Upper(cFile),"DBF","FPT")))
SELF:WriteCgiLog ("altes File konnte nicht gelöscht werden "+String2Psz (StrTran (Upper(cFile),"DBF","FPT")))
SELF:Err_DeleteFile (String2Psz (StrTran (Upper(cFile),"DBF","FPT")), "Kontroll_Ein_Insert")
ENDIF
Maybe Robert will be able to find the problem by looking at the dbf/fpt alone. But this is not gonna be easy, so could you please also prepare a small standalone (compilable) sample that reproduces this problem?
Thanks, I see the problem, but only happens with the existing temp dbf/fpt files, if I create new ones, then it works fine. Not sure yet if it's a problem in the files themselves or in the X# RDD, but how where those files created? Where they created by a VO, X# or other app?