VFP9 with CDX concerns ?

[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

[lumberjack]

Hi Dexter,

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.

[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

[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

[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 ]

[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

[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

[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

[DexterZ]

Hi Karl,

FLUSH is more on OS disk caching, while COMMIT is internal to application saving scheme ^_^y

Dex

[robert]

Dex,

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