Subject | RE: [ib-support] Post in transaction |
---|---|
Author | Wilson, Fred |
Post date | 2003-02-20T15:44:44Z |
Well that's certainly a problem with the design of the client application.
You're really fighting the "built in" ability that FB has regarding the "all
or nothing" approach.
We carry our data around in structures (list and such), and never rely on
database components that trash themselves (data).
We fought that sillyness, years ago when we first started, and quickly
ditched the database aware components. None of them really had the totally
"look and feel" of Windows, anyway.
By far, IMHO, is to work out a better design of your application, rather
than spend tons of time fighting a bad design.
If there is no way to retain the data, then something is obvious wrong.
FWIW's, we never have used any database aware components. We don't even use
any commercial third market components, for some of the same reason(s).
We've simply written two layers above the FB API. This allows use to use any
database that we would choose, in the future, and all that we would have to
change would be the datamod layers.
Best regards,
Fred Wilson
SE, Böwe Bell & Howell
fred.wilson@...
-----Original Message-----
From: Burak OZLER [mailto:burak.ozler@...]
Sent: Thursday, February 20, 2003 12:21 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] Post in transaction
if you rollback whole transaction you'll loose the data on the form that are
DB_Aware..
Regards
Burak.
You're really fighting the "built in" ability that FB has regarding the "all
or nothing" approach.
We carry our data around in structures (list and such), and never rely on
database components that trash themselves (data).
We fought that sillyness, years ago when we first started, and quickly
ditched the database aware components. None of them really had the totally
"look and feel" of Windows, anyway.
By far, IMHO, is to work out a better design of your application, rather
than spend tons of time fighting a bad design.
If there is no way to retain the data, then something is obvious wrong.
FWIW's, we never have used any database aware components. We don't even use
any commercial third market components, for some of the same reason(s).
We've simply written two layers above the FB API. This allows use to use any
database that we would choose, in the future, and all that we would have to
change would be the datamod layers.
Best regards,
Fred Wilson
SE, Böwe Bell & Howell
fred.wilson@...
-----Original Message-----
From: Burak OZLER [mailto:burak.ozler@...]
Sent: Thursday, February 20, 2003 12:21 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] Post in transaction
if you rollback whole transaction you'll loose the data on the form that are
DB_Aware..
Regards
Burak.
----- Original Message -----
From: Wilson, Fred
To: 'ib-support@yahoogroups.com'
Sent: Wednesday, February 19, 2003 6:34 PM
Subject: RE: [ib-support] Post in transaction
Understand. What's the problem with rolling the whole transaction back
(assuming only one transaction), then simply having the user correct (on
the
form), whatever's wrong
Best regards,
Fred Wilson
SE, Böwe Bell & Howell
fred.wilson@...
-----Original Message-----
From: Burak OZLER [mailto:burak.ozler@...]
Sent: Wednesday, February 19, 2003 8:24 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] Post in transaction
yes all or nothing...
if the procedures gets an error then I want to give the user a chance
to
correct the values that s/he entered the form by rollbacking the second
not
rollback all the data. Indeed I need nested transactions but firebird
doesn't support it yet..
regards
burak..
----- Original Message -----
From: Wilson, Fred
To: 'ib-support@yahoogroups.com'
Sent: Wednesday, February 19, 2003 4:55 PM
Subject: RE: [ib-support] Post in transaction
Sounds like you're interested in a "all or nothing" thing, that is, all
the
SQL statements must succeed or you want none of them to succeed. A
single
transaction does just that, either commit or rollback..
If that's not what you're trying to do, please explain further.
Best regards,
Fred Wilson
SE, Böwe Bell & Howell
fred.wilson@...
-----Original Message-----
From: Burak OZLER [mailto:burak.ozler@...]
Sent: Wednesday, February 19, 2003 7:21 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] Post in transaction
I need the second Transaction becouse of data security.
I start a transaction then I run lots of procedures in an other
transaction
if procedures works well then I commit trn2 then trn first.
----- Original Message -----
From: benno
To: ib-support@yahoogroups.com
Sent: Wednesday, February 19, 2003 4:11 PM
Subject: Re: [ib-support] Post in transaction
Hi,
----- Original Message -----
From: "Burak OZLER" <burak.ozler@...>
To: <ib-support@yahoogroups.com>
Sent: Wednesday, February 19, 2003 3:02 PM
Subject: [ib-support] Post in transaction
> Hi all,
>
> I have a problem that must have solved very urgently.
>
> 1 - I start a transaction1
> 2 - Edit AA
> 3 - Change a value at table AA
> 4 - Post AA
> 5 - Start transaction2
> 5 - Change or insert a record to an another table (BB), one field at
BB
references a field at AA
> 6 - The referenced value at BB is the row at AA that was edited and
posted.
> 7 - When I try to post the data at BB I get an
> "lock conflict on no wait transaction
> violation of FOREIGN KEY constrait "FK_XXX" on table "BB"."
> error.
>
> how can I achive to post the BB before committing transaction1??
>
> I hope I could explain the stuation??
I think you can do this by doing both in Transaction 1. Why do you
need
2
transactions?
Benno
To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
------------------------------------------------------------------
Virus taramasi yapildi. Scanned for Viruses. [19/02/2003 - 16:14]
[Non-text portions of this message have been removed]
To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
[Non-text portions of this message have been removed]
To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
------------------------------------------------------------------
Virus taramasi yapildi. Scanned for Viruses. [19/02/2003 - 16:58]
[Non-text portions of this message have been removed]
To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[Non-text portions of this message have been removed]
To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
------------------------------------------------------------------
Virus taramasi yapildi. Scanned for Viruses. [19/02/2003 - 18:44]
[Non-text portions of this message have been removed]
To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
[Non-text portions of this message have been removed]