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?

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

Post by 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

[Craig Stuntz [TeamB]]

Post by Mark Patterson
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.

[Mark Patterson]

Post by Craig Stuntz [TeamB]

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

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;

Post by Craig Stuntz [TeamB]
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.

[Craig Stuntz [TeamB]]

Post by Mark Patterson

Post by Craig Stuntz [TeamB]
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.

Post by Mark Patterson
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.