Board index » delphi » Update Data Records Changes - URGENT URGEN URGENT

Update Data Records Changes - URGENT URGEN URGENT

In 1997 i have maden one Program to an insurance Company, but yesterday
it happen something very important....

After change some data Records, the Computer crashed, and didn's update
tha DataBase Records tha i have changed...

Question: How could i make the update records each five minuts (PARADOX
DATABASES - WITH DELPHI 2.0)?

Answer: I know that i need to use a TTimer, but the other else i don't
Know, Could someone help me?

I need to correct this big mistake, to receive my payment....

 

Re:Update Data Records Changes - URGENT URGEN URGENT


Marco Antonio Soares Branco <etma...@student.ua.pt> wrote in message
news:3810897C.3D8B@student.ua.pt...

Quote
> In 1997 i have maden one Program to an insurance Company, but yesterday
> it happen something very important....

> After change some data Records, the Computer crashed, and didn's update
> tha DataBase Records tha i have changed...

> Question: How could i make the update records each five minuts (PARADOX
> DATABASES - WITH DELPHI 2.0)?

> Answer: I know that i need to use a TTimer, but the other else i don't
> Know, Could someone help me?

> I need to correct this big mistake, to receive my payment....

Are you sure you're attacking the cause and not the symptom? Is
it *your* program that's causing the computer to crash? Anyway,
that's another question.

To clear out all of the database buffers, drop a timer on your
main form and set the interval to 300000 (5 mins). In the
OnTimer event, write something like this:

procedure Timer1.Timer(Sender : TObject);
var
  i : integer;
begin
  with DataModule1 do
    for i := 0 to ComponentCount - 1 do
      if Components[i] is TTable then
        if TTable(Components[i]).Active then
          TTable(Components[i]).FlushBuffers;
end;

(You can modify this to work for TQueries too, but it doesn't work
for all types of table, for example Access tables).

I think Bruce Roberts warned against using a timer because of the
danger of saving un-posted records - I don't actually think this is
the case - only newly posted records are in the buffer.

The most important thing you can do is *only open the tables when
you need them*. If a table is "closed" (Active := False) and the
application crashes, then it doesn't matter. This will probably require
quite a bit of extra work, but it's worth it.

Attaching "URGENT URGENT URGENT" to your post does you no
favours at all, BTW.

--
Jeremy Collins
Kansai Business Systems
http://www.kansai.co.uk/

Re:Update Data Records Changes - URGENT URGEN URGENT


Quote
Jeremy Collins <jer...@kansai.co.uk> wrote in message

news:940583062.16280.0.nnrp-03.c2de6535@news.demon.co.uk...

Quote

> I think Bruce Roberts warned against using a timer because of the
> danger of saving un-posted records - I don't actually think this is
> the case - only newly posted records are in the buffer.

I think you will find that a call to FlushBuffers will post any table in
dsEdit or dsInsert state. This means that a partially completed record could
be posted if the user is in the middle of editing it. dbiSaveChanges, on the
other hand, doesn't appear to. What I do not completely understand is the
apparent reluctance to use the very simple solution of setting LOCAL SHARE
to true. Does anyone out there have experience (or direct knowledge) that
would indicate that this setting does not force write through of posts?
Quote
> --
> Jeremy Collins
> Kansai Business Systems
> http://www.kansai.co.uk/

Re:Update Data Records Changes - URGENT URGEN URGENT


On Fri, 22 Oct 1999 14:57:29 GMT, "Bruce Roberts"

Quote
<no.junk.please....@attcanada.net> wrote:
>>I think you will find that a call to FlushBuffers will post any table in
>>dsEdit or dsInsert state. This means that a partially completed record could

My experience is that until a Post is called then there is nothing to
Flush?? I must say I haven't tested to see if it in fact does flush
the current record, regardless.

Flushing a partially changed record doesn't sound right to me as until
Post is called there is also the posibility of a Cancel, so it would
be reckless of Paradox to flush in anticipation of there being a Post
and *not* a Cancel.

I haven't used LocalShare but it seems to be a backdoor method when
you have FlushBuffers available, or to a lesser extent,
CheckBrowseMode.

--

Grumpy, the Third Dwarf
(Dave Johnson)

*****************************************
If I were taller, I wouldn't be so short!
      Dyslexics of the world, untie
*****************************************

Re:Update Data Records Changes - URGENT URGEN URGENT


On Fri, 22 Oct 1999 09:36:24 +0100, "Jeremy Collins"

Quote
<jer...@kansai.co.uk> wrote:
>>To clear out all of the database buffers, drop a timer on your
>>main form and set the interval to 300000 (5 mins). In the
>>OnTimer event, write something like this:

>>          TTable(Components[i]).FlushBuffers;

  if NotFlushedYet[i] then
  begin
    TTable(Components[i]).FlushBuffers;
    NotFlushedYet[i]:=False;
  end;

What's wrong with a FlushBuffers in the AfterPost event?

I Open a dataset when Activating and close it when Deactivating, but
do a FlushBuffers in the AfterPost. It may suggest some disk-thrashing
but in real terms the bulk of the database data is not being
changed/inserted all that often.

I have found over a long period of time and number of databases, that
most calls to a database are reference calls *for* data by a ratio of
about 10:1 so calling for a Flush after a Post seems the approach to
me.

Even when updating it is usually an ancilliary dataset and not the
main information datasets that are being updated or inserted to.

In an accounting system for instance, there might be 5 or 6 ancilliary
datasets but only the "Orders" might be changed or added to so the
actual amount of disk writing going on is still minimal.

So, again, what's wrong with a Flush AfterPost?? Have I been doing it
wrong all these years?? <g>

On another subject, I agree with Jeremy, "Urgent" in the subject is a
good way to have your posts ignored.

--

Grumpy, the Third Dwarf
(Dave Johnson)

*****************************************
If I were taller, I wouldn't be so short!
      Dyslexics of the world, untie
*****************************************

Re:Update Data Records Changes - URGENT URGEN URGENT


Quote
Bruce Roberts <no.junk.please....@attcanada.net> wrote in message

news:tX_P3.20$IK1.32@cabot.ops.attcanada.net...

Quote

> Jeremy Collins <jer...@kansai.co.uk> wrote in message
> news:940583062.16280.0.nnrp-03.c2de6535@news.demon.co.uk...

> > I think Bruce Roberts warned against using a timer because of the
> > danger of saving un-posted records - I don't actually think this is
> > the case - only newly posted records are in the buffer.

> I think you will find that a call to FlushBuffers will post any table in
> dsEdit or dsInsert state. This means that a partially completed record could
> be posted if the user is in the middle of editing it. dbiSaveChanges, on the
> other hand, doesn't appear to.

I just made a couple of tests, and yep, you're right. And now I think about
it, D'OH! I always used to use dbiSaveChanges, and I made the switch to
FlushBuffers because I perceived it as "safer". This safety came from the
call to CheckBrowseMode in FlushBuffers, and of course CheckBrowseMode
posts all pending changes. I committed the sin of not re-testing my code
after switching to FlushBuffers.

Mental processes adjusted accordingly <g>

Quote
>What I do not completely understand is the
> apparent reluctance to use the very simple solution of setting LOCAL SHARE
> to true. Does anyone out there have experience (or direct knowledge) that
> would indicate that this setting does not force write through of posts?

Dunno - your post was the first time I heard of this solution. I
remember fiddling about with BDE settings for *hours* when D2 was
released to get over various problems, including un-saved cached data,
and I never discovered this.

Another case of mindset, probably.

--
Jeremy Collins
Kansai Business Systems
http://www.kansai.co.uk/

Re:Update Data Records Changes - URGENT URGEN URGENT


Grumpy, the Third Dwarf <grumpyoldf...@attglobal.net> wrote in message
news:3813896d.4066418@news1.attglobal.net...

Quote

> My experience is that until a Post is called then there is nothing to
> Flush?? I must say I haven't tested to see if it in fact does flush
> the current record, regardless.

Do the test. I think you'll be suprised.

Quote

> Flushing a partially changed record doesn't sound right to me as until
> Post is called there is also the posibility of a Cancel, so it would
> be reckless of Paradox to flush in anticipation of there being a Post
> and *not* a Cancel.

It isn't really reckless since the programmer called for the action. And, it
isn't Paradox doing it but the Delphi VCL.

Quote

> I haven't used LocalShare but it seems to be a backdoor method when
> you have FlushBuffers available, or to a lesser extent,
> CheckBrowseMode.

An unusual characterization. The method seems pretty legitimate to me,
especially if the program forces the setting of LOCAL SHARE.
Quote

> --

> Grumpy, the Third Dwarf
> (Dave Johnson)

> *****************************************
> If I were taller, I wouldn't be so short!
>       Dyslexics of the world, untie
> *****************************************

Re:Update Data Records Changes - URGENT URGEN URGENT


On Fri, 22 Oct 1999 21:15:44 GMT, "Bruce Roberts"

Quote
<no.junk.please....@attcanada.net> wrote:
>>> Flushing a partially changed record doesn't sound right to me as until
>>> Post is called there is also the posibility of a Cancel, so it would
>>> be reckless of Paradox to flush in anticipation of there being a Post
>>> and *not* a Cancel.

>>It isn't really reckless since the programmer called for the action. And, it
>>isn't Paradox doing it but the Delphi VCL.

True, I was paraphrasing since both Paradox and Delphi are from the
same stable and what one does the other mimics just the VCL does it
more easily. There is a flush in paradox too and I also doubt it would
do a write before a Post, my guess is still that the buffer is only
updated after a Post, so Flush will only write what is in the "Post"ed
buffer.

It doesn't make sense to write a record that is in Edit or Insert
mode. Not even Ashton Tate would have done that. <g>

Quote
>>An unusual characterization. The method seems pretty legitimate to me,
>>especially if the program forces the setting of LOCAL SHARE.

To each his own I guess.

--

Grumpy, the Third Dwarf
(Dave Johnson)

*****************************************
If I were taller, I wouldn't be so short!
      Dyslexics of the world, untie
*****************************************

Re:Update Data Records Changes - URGENT URGEN URGENT


Grumpy, the Third Dwarf <grumpyoldf...@attglobal.net> wrote in message
news:3811fcde.33623856@news1.attglobal.net...

Quote
> On Fri, 22 Oct 1999 21:15:44 GMT, "Bruce Roberts"
> <no.junk.please....@attcanada.net> wrote:

<snip>

Quote
> It doesn't make sense to write a record that is in Edit or Insert
> mode. Not even Ashton Tate would have done that. <g>

It may not make sense but that is in fact what FlushBuffers does. This fact
is documented in the help on the routine.
Quote

> >>An unusual characterization. The method seems pretty legitimate to me,
> >>especially if the program forces the setting of LOCAL SHARE.

> To each his own I guess.

> --

> Grumpy, the Third Dwarf
> (Dave Johnson)

> *****************************************
> If I were taller, I wouldn't be so short!
>       Dyslexics of the world, untie
> *****************************************

Re:Update Data Records Changes - URGENT URGEN URGENT


On Sat, 23 Oct 1999 04:27:08 GMT, "Bruce Roberts"

Quote
<no.junk.please....@attcanada.net> wrote:
>>> It doesn't make sense to write a record that is in Edit or Insert
>>> mode. Not even Ashton Tate would have done that. <g>

>>It may not make sense but that is in fact what FlushBuffers does. This fact
>>is documented in the help on the routine.

It may in *your* help file but in mine...

Quote, copied and pasted...
******************** Copyright Borland ************************
FlushBuffers posts all changes that have been written to the record
buffer.

procedure FlushBuffers;

Description

Call FlushBuffers to cause the dataset to post all pending changes to
the database, including any cached updates. Use FlushBuffers instead
of CheckBrowseMode if it is important that cached record buffers are
posted.
*****************************************************************

Err,

"**written** to the record buffer."
"including any **cached** updates"

what part of that don't you understand??

How can they be "cached" if they haven't been Post'ed?

--

Grumpy, the Third Dwarf
(Dave Johnson)

*****************************************
If I were taller, I wouldn't be so short!
      Dyslexics of the world, untie
*****************************************

Re:Update Data Records Changes - URGENT URGEN URGENT


Grumpy, the Third Dwarf <grumpyoldf...@attglobal.net> wrote in message
news:3812e752.3231823@news1.attglobal.net...

Quote

> It may in *your* help file but in mine...

> Quote, copied and pasted...
> ******************** Copyright Borland ************************
> FlushBuffers posts all changes that have been written to the record
> buffer.

> procedure FlushBuffers;

> Description

> Call FlushBuffers to cause the dataset to post all pending changes to
> the database, including any cached updates. Use FlushBuffers instead
> of CheckBrowseMode if it is important that cached record buffers are
> posted.
> *****************************************************************

I guess we just interpret things differently. If I do

aTable.Edit;
aTable ['a Field'] := aValue;

have I not made a change which is pending? In any case its a moot discussion
since FlushBuffers does do a Post.

- Show quoted text -

Quote
> Err,

> "**written** to the record buffer."
> "including any **cached** updates"

> what part of that don't you understand??

> How can they be "cached" if they haven't been Post'ed?

Other Threads