APPEND BLANK is not realtime... Please help. 3

[Mandy_crw]

Hi everyone... am i missing something in the codes? it does not add record or i mean it does not append realtime, it appends new record when the application is closed.... Please help... Thanks and God Bless....


SELECT 3

araw = CDOW(DATE())
notif = tsulat.ctr - 1
x = " "

if notif = 0 or notif = 2
x = "IN"
ELSE
x = "OUT"
ENDIF

APPEND BLANK
REPLACE rek.idnum WITH this.value
REPLACE rek.time WITH DATETIME()
REPLACE rek.lname WITH this.parent.text2.value
REPLACE rek.kol WITH x
REPLACE rek.dey WITH araw

this.value = " "
this.parent.text2.value = ""
this.Parent.text3.value = ""
RETURN 0

 

[tomk3]

Hello,

if it is not a GUI (Update screen) issue, you may try :
goto recno()) or skip (0) or flush force after append.

In our programs we switched to insert into ... syntax as suggested by Mike some time ago.
(In fact we use gather memo blank name thisform.odat, set/validate values ,... and then insert into ... from name thisform.odat)

regards
tom

 

[Mandy_crw]

hi everyone... mike & tomk3... I have tried almost everything that I know to solve my problem with everyone's help ofcourse.... thank you so much.... I've used the flush as suggested by tom and mike... thanks for all your help... My application is now up and running God bless....

 

[Mike Lewis]

Delighted to hear it, Mandy.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[mjcmkrsr]

Hi Mandy,

FLUSH may have helped you out of the deadlock, but surely is not a definite solution. Please read below (from Hacker's Guide to Visual Foxpro 7 by T. Granor, T. Roche et al)

FLUSH empties all internal buffers of data (which have nothing to do with record or table buffering) to be written to disk. Buffers are automatically flushed when the table is closed or a record is unlocked.

In rare cases, the loss of a computer or the network before all disk writes are completed can result in the loss of data within a record, or even the corruption of a table header, leading to the dreaded "Not a table" error message. Visual FoxPro and its immediate predecessors seem to be better at this than the bad old days of dBASE III and FoxBase, but we're not sure how much of this is due to improvements in the product and how much is due to more reliable hardware and much more common UPSes. Also, new logic was added into the process of opening a file in VFP, so that if it detects the header is "one off" from the actual record count, it just increments the header count, invisibly and silently, and continues the file-open process. In addition, because releasing record and file locks automatically flushes the data (although not the file headers), the increased popularity of rapid lock-update-unlock techniques has probably also contributed to the overall reliability of our systems. Row- and table-buffering techniques that also commit data to disk as rapidly as possible alleviate most of the need for this command.

However, in Doug's experience, buffering seems to update the data records, but not always the table and memo headers. Even an explicit FLUSH may not be the solution—he reports that FLUSH updates the table and memo file headers but not the CDX header. Closing a file, issuing an explicit FLUSH, or waiting for the timeout for automatic flushing (we think that that is five minutes, set internally and inaccessible to us) may still not be sufficient for the most paranoid. Realistically, the command is a FoxPro solution for something that is not a FoxPro problem—the problem is the environment in which you are asking FoxPro to perform. If your network suffers frequent crashes, fix it. Until you can, consider FLUSHes as a Band-Aid to lower the frequency of, but not necessarily eliminate, file corruption. If the crashing can't be stopped, consider a more robust data storage technique like client-server instead of the direct writing to ISAM files of the FoxPro DBF model.

Forcing a FLUSH defeats the automated caching of Visual FoxPro and leads to degraded performance. Because writes are performed automatically upon the release of locks, the only situations in which FLUSH is likely to save more data is where tables are being bulk-updated in an exclusive or file-locked situation.

Bottom line: If you're losing a lot of data, you can use FLUSH to improve the situation a little. But improving the online reliability of your system will be a far better long-term investment. We don't use this command much at all.

hth

MarK

 

[TamarGranor]

Reading this, I really wonder what the current work area is. If the table in the current work area is at EOF(), then REPLACE won't work in another work area unless you use the IN clause.

Tamar

 

[Mike Lewis]

I really wonder what the current work area is. If the table in the current work area is at EOF(), then REPLACE won't work in another work area unless you use the IN clause.

This goes back to what I said at the very start of the thread. The selected work area is number 3, but the alias being updated is named "rek". We have no way of knowing if "rec" and number 3 are the same work area.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Harry_Clipper]

Hello Mandy,

try the FLUSH command after the replace commands.

hth

harald

 

[Mandy_crw]

Hi Mike and Tamar, I have these codes in the initialization part....

SELECT 3
USE smsrec exclusive ALIAS rek

SELECT 2
USE payments exclusive ALIAS pay
INDEX on idnum TO pidnumx

SELECT 1
USE sms exclusive ALIAS tsulat
INDEX on idnum TO idnumx


Thanks Harry ive used FLUSH command and it worked.... thanks...

 

[TamarGranor]

Please don't ever write code that mentions specific work areas again. You should never know or care what work area a table is open in. Much better to use SELECT 0, which switches to the next available work area.

Also, you don't need to index a table every time you open it. Indexes stick around. In addition, unless you are using a version earlier than FoxPro 2.0, you should never use INDEX ... TO ...; always use INDEX ... TAG ..., so all your index tags go into a single CDX file that is automatically opened when your table opens. That way, you know that your indexes always get updated properly.

So, I would write your code like this (after recreating your indexes properly):

SELECT 0
USE smsrec exclusive ALIAS rek

SELECT 0
USE payments exclusive ALIAS pay ORDER pidnumx

SELECT 0
USE sms exclusive ALIAS tsulat ORDER idnumx

All that said, if you actually change your indexes, you'll likely have to change code elsewhere in your application. You use SET ORDER TO, not SET INDEX TO, to specify the order you want and so forth.

Tamar

 

[Mandy_crw]

Ok I will, Thanks so much Tamar...