Page 2 of 4
VFP9 with CDX concerns ?
Posted: Tue Jan 21, 2020 1:01 pm
by DexterZ
Nyaha,
I tried using X# VFP dialoect solution but FAILED ( see my code in X# on VFP dialect from my post ), and I tried calling it directly to C# and has no problem : - )
My I idea is to write a library that can manipulate Dbf using X# any dialects will do as Im very familiar in dBase,Clipper,Harbor,FoxBase and VFP 2.5 to 9 : ) and call that library to any .NET application C#,VB,F# ^_^Y
Cheers Sir Johan ^_^y
VFP9 with CDX concerns ?
Posted: Wed Jan 22, 2020 6:21 am
by lumberjack
Hi Dexter,
DexterZ wrote:
I tried using X# VFP dialoect solution but FAILED ( see my code in X# on VFP dialect from my post ), and I tried calling it directly to C# and has no problem : - )
My I idea is to write a library that can manipulate Dbf using X# any dialects will do as Im very familiar in dBase,Clipper,Harbor,FoxBase and VFP 2.5 to 9 : ) and call that library to any .NET application C#,VB,F# ^_^Y
Only real problem I see with your original code is the REPLACE command.
If you FieldPut("ColName", ColValue) you should be fine. And just add a COMMIT afterwards.
VFP9 with CDX concerns ?
Posted: Wed Jan 22, 2020 10:44 am
by DexterZ
Hello Johan,
[ "Only real problem I see with your original code is the REPLACE command" ]
If I run the code below using Foxpro Console Application solution with the attached DBF/CDX ( kindly use my attachement replied to Chris) and browse it, the data is still empty, because it failed the reason I tried to use C# directly.
Code: Select all
FUNCTION Start() AS VOID STRICT
SELECT 0
USE "C:TEMPTESTDB.DBF" SHARED
APPEND BLANK
*
Replace DOC_TYPE with "RR" ,;
DOC_NO with "12345"
WAIT "Press a key to exit ^_^"
RETURN
[ "If you FieldPut("ColName", ColValue) you should be fine. And just add a COMMIT afterwards." ]
I don't think
FieldPut has a "
field name" overloads? it only accept "
field index"
Dex
VFP9 with CDX concerns ?
Posted: Wed Jan 22, 2020 11:06 am
by Karl-Heinz
Hi Dex,
simply add a COMMIT and CLOSE command, similar you´re already doing in you C# app
Code: Select all
FUNCTION Start() AS VOID STRICT
SELECT 0
USE "C:TEMPTESTDB.DBF" SHARED
APPEND BLANK
*
Replace DOC_TYPE with "RR" ,;
DOC_NO with "12345"
commit // <-------------
close // <--------------
WAIT "Press a key to exit ^_^"
RETURN
regards
Karl-Heinz
VFP9 with CDX concerns ?
Posted: Wed Jan 22, 2020 1:37 pm
by DexterZ
YAY! You hit the nail on the head Karl! ^_^Y
The thing is COMMIT and CLOSE are not necessary in FoxBase/FoxPro/VFP to reflect the changes, the reason I didn't think to add commit and close ; ) good to know it's needed in X#
Thank you guyz for all the help,
Dex
[ CASE CLOSED ]
VFP9 with CDX concerns ?
Posted: Wed Jan 22, 2020 2:20 pm
by FoxProMatt
Indeed, in VFP we do not use any commands to "commit" data changes to the current row, *EXCEPT* if we have enabled Table Buffering. In this case, you have to call TableUpdate() to write the changes.
I know that a LOT of people use Table Buffering in VFP apps, so X# will have to address this issue for full FoxPro compatibility.
Here are the main functions involved in Table Buffering:
Code: Select all
*-- Specifies property settings for a Visual FoxPro table or a cursor.
CURSORSETPROP( cProperty [, eExpression] [,cTableAlias | nWorkArea])
*-- Retrieves the current property settings for a Visual FoxPro table or a cursor.
CURSORGETPROP(cProperty [, nWorkArea | cTableAlias])
*-- Commits changes made to a buffered row, a buffered table, cursor, or cursor adapter.
TABLEUPDATE( [nRows [, lForce]] [, cTableAlias | nWorkArea] [, cErrorArray] )
*-- Discards changes made to a buffered row or a buffered table or cursor and restores the OLDVAL( ) data for remote cursors and the current disk values for local tables and cursors.
TABLEREVERT( [lAllRows [, cTableAlias | nWorkArea] ] )
Here is an example which shows several of the functions that are in play when Table Buffering is used:
Code: Select all
*---------------------------------------------------------------*
* If any changes have been made to the table or record, prompt the
* user to save the changes. If the user says 'yes,' all changes
* are saved. Any changes made to the data by other users after
* this user made the change and before the change was committed
* will be lost.
*
* RETURNS NUMERIC VALUES:
* 0 -- No Changes Made to the Current Values
* 1 -- Successfully Made All User Changes
* 2 -- Unable to Write One or More User-Specifed Changes to Table
*---------------------------------------------------------------*
* Declare constants & variables
#define SAVECHG_LOC 'Do you want to save your changes?'
#define SAVECHG2_LOC 'Save Changes'
#define NOBUFF_LOC2 'Data buffering is not enabled.'
LOCAL lnChoice, llMadeChange, lnSuccess
m.llMadeChange = .F.
m.lnSuccess = 0
* If the user has changed anything, prompt to save or discard changes
DO CASE
CASE INLIST(CURSORGETPROP('Buffering'), 2,3) && Row Buffering
IF '2' $ GETFLDSTATE(-1)
m.llMadeChange = .T.
ENDIF
CASE INLIST(CURSORGETPROP('Buffering'), 4,5) && Table Buffering
IF GETNEXTMODIFIED(0) > 0
m.llMadeChange = .T.
ENDIF
OTHERWISE
WAIT WINDOW NOBUFF_LOC NOWAIT
ENDCASE
IF m.llMadeChange
m.lnChoice = MESSAGEBOX(SAVECHG_LOC, 4+32, SAVECHG2_LOC)
IF m.lnChoice = 6 && Yes
m.lnSuccess = IIF(TABLEUPDATE(.T.,.T.), 1, 2)
ELSE
=TABLEREVERT(.T.)
ENDIF
ENDIF
RETURN m.lnSuccess
VFP9 with CDX concerns ?
Posted: Wed Jan 22, 2020 3:58 pm
by Karl-Heinz
Matt,
it´s been ages ago that i used DBF commands. Just to be more precise, the current behaviour is: Doing it without a COMMIT and without a CLOSE the values are not written. But the values are written when i do either a COMMIT or a CLOSE.
BTW. Fox knows the command FLUSH, isn ´t that the same as COMMIT ?
regards
Karl-Heinz
VFP9 with CDX concerns ?
Posted: Wed Jan 22, 2020 4:05 pm
by DexterZ
Hi Matt,
The problem is if I use a DBF file without a CDX file, I don't need to add COMMIT and CLOSE. the REPLACE command reflect the changes to the DBF.
The problem only arises when I used a DBF file that has a CDX file, REPLACE command is not suffice.
and I need add to COMMIT and CLOSE it just to reflect the changes T_T
------------------------------------
Thank's for the tip on buffering, I think I know how table/storage buffering works in VFP but I preferred to use FLUSH command ( OS related disk caching ) over VFP table buffering ( VFP table/storage buffering ).
Whether using Replace, Insert, Tableupdate or any saving commands... if you pull the machine's power plug some data will be lost, unless you issue FLUSH command after any saving/update commands.
On my experience VFP running on Windows 7 to 10 needs FLUSH it has some disk caching delay on this latest MS OS : )
Many thanks,
Dex
VFP9 with CDX concerns ?
Posted: Wed Jan 22, 2020 4:11 pm
by DexterZ
Hi Karl,
FLUSH is more on OS disk caching, while COMMIT is internal to application saving scheme ^_^y
Dex
VFP9 with CDX concerns ?
Posted: Wed Jan 22, 2020 4:50 pm
by robert
Dex,
DexterZ wrote:
The problem is if I use a DBF file without a CDX file, I don't need to add COMMIT and CLOSE. the REPLACE command reflect the changes to the DBF.
The problem only arises when I used a DBF file that has a CDX file, REPLACE command is not suffice.
and I need add to COMMIT and CLOSE it just to reflect the changes T_T
I'll check why the program does not automatically commit the changes at shutdown.
Robert