Reopened dataset doesn't show change

[Mark Patterson]

Hi,

I am deleting a record, which the user selects from a DBGrid in a dialog
window, then reopening the dataset attached to the grid, but the deleted
record is still there. If I close that dialog window and reopen it, the
record is still there. But it has gone in FlameRobin.

If I close the application and fire it up again, then open this dialog,
the offending record is gone.

I think this has something to do with transactions. After the delete I
do CommitRetaining. Any ideas?

--
Mark Patterson
www.piedsoftware.com

[Ömür Ölmez]

If it has gone in FlameRobin but you can still see in your dataset then,
you deleted the record but you did not restart your transaction which your
viewing dataset is connected to.
You should call transaction commit or rollback before re open dataset.

Ömür

"Mark Patterson" <nos...@stopbots.com> wrote in message
news:489056f8$1...@newsgroups.borland.com...

[Craig Stuntz [TeamB]]

Mark Patterson wrote:

> I think this has something to do with transactions. After the delete
> I do CommitRetaining. Any ideas?

It sounds as though two things have happened:

1. The SELECT is running in the context of a snapshot transaction.
That is probably not what you want. Generally, used read committed
unless you have a reason to do otherwise.

2. You are never committing the transaction in which the SELECT
statement is running. In recent versions of InterBase (7.5+), that is
fine for a read-only, read-committed transaction. But it doesn't sound
like that's what you're using. With older versions of InterBase, you
must commit the transaction in a timely manner, in all cases.

--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz
Want to help make Delphi and InterBase better? Use QC!
http://qc.borland.com -- Vote for important issues

[Mark Patterson]

Craig Stuntz [TeamB] wrote:
> Mark Patterson wrote:
>
>> I think this has something to do with transactions. After the delete
>> I do CommitRetaining. Any ideas?
>
> It sounds as though two things have happened:
>
> 1. The SELECT is running in the context of a snapshot transaction.
> That is probably not what you want. Generally, used read committed
> unless you have a reason to do otherwise.

I am not familiar with the idea of "read committed", though I notice
this line in IBHeader:
isc_tpb_read_committed = 15;

> 2. You are never committing the transaction in which the SELECT
> statement is running. In recent versions of InterBase (7.5+), that is
> fine for a read-only, read-committed transaction. But it doesn't sound
> like that's what you're using. With older versions of InterBase, you
> must commit the transaction in a timely manner, in all cases.

Not being rich and famous, I'm just using Firebird at present.

--
Mark Patterson
www.piedsoftware.com

[Craig Stuntz [TeamB]]

Mark Patterson wrote:

> > 1. The SELECT is running in the context of a snapshot transaction.
> > That is probably not what you want. Generally, used read committed
> > unless you have a reason to do otherwise.
>
> I am not familiar with the idea of "read committed", though I notice
> this line in IBHeader: isc_tpb_read_committed = 15;

OK that I suggest that you should read the manual about transaction
isolation modes. You are asking about an isolation problem, so you
need to understand this.

> Not being rich and famous, I'm just using Firebird at present.

I don't know a lot about Firebird, but I'll presume that it behaves
the same as older versions of InterBase, meaning that it is never safe
to keep a transaction open forever.

--
Craig Stuntz [TeamB] · Vertex Systems Corp. · Columbus, OH
Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz

Everything You Need to Know About InterBase Character Sets:
http://blogs.teamb.com/craigstuntz/articles/403.aspx