firebird-net-provider

Re: [Firebird-net-provider] Feature Request: Multiple Transactions per Connection....

[Lee C. <lee...@ad...>]

Hi Willibald,

I am not sure I totally understood what you said but wouldn't you in a =
case like this need to use only 1 connection to the database?  You send =
1 transaction at a time updating those seperate windows.  The only way =
"I" see it (like i said i might be missing something) is that you want =
to run multi-threaded app that can send concurrent transactions?

Lee

"Willibald Krenn" <wi...@dw...> wrote in message =
news:bftn6d$5up$1...@ne......
> Hi!
>=20
> I'm using the Firebird ADO.NET provider 1.0 for some time now and I =
have to
> say that it's well done.

Re: [Firebird-net-provider] Feature Request: Multiple Transactions per Connection....

[Willibald K. <wi...@dw...>]

""Lee Connell"" <lee...@ad...> schrieb im Newsbeitrag
news:019101c35375$b62d5890$0c00a8c0@s0phtinc...
>
> Hi Willibald,

Hi Lee,

> I am not sure I totally understood what you said but wouldn't you in a =
> case like this need to use only 1 connection to the database?  You send =
> 1 transaction at a time updating those seperate windows.  The only way =
> "I" see it (like i said i might be missing something) is that you want =
> to run multi-threaded app that can send concurrent transactions?

Well, if an user goes into 'edit' mode in one of the windows, I could do a
dummy update in the transaction that's responsible for that window (to lock
the record). If the user now (window 1 is in edit mode) decides to open
another window, I can not just commit the changes from window 1 and use the
transaction to open window 2. If you've read
http://www.interbase-world.com/modules.php?name=News&file=article&sid=423 ,
you'll understnd that I want to use transactions for 'locking' records.

Of course it would also be a nice feature to be able to run a report in a
separate thread, using the same connection. But I already need more than one
transaction per Client without going multi-thread.

Willi

Re: [Firebird-net-provider] Feature Request: Multiple Transactions per Connection....

[Carlos G. A. <car...@te...>]

Hello:

> Well, if an user goes into 'edit' mode in one of the windows, I could do a
> dummy update in the transaction that's responsible for that window (to lock
> the record). If the user now (window 1 is in edit mode) decides to open
> another window, I can not just commit the changes from window 1 and use the
> transaction to open window 2. If you've read
> http://www.interbase-world.com/modules.php?name=News&file=article&sid=423 ,
> you'll understnd that I want to use transactions for 'locking' records.

One question in your scenario the connection is open permanently ?? ( I 
ask this because we need to think that ADO .NET is designed for work in 
disconnected mode )




-- 
Best regards

Carlos Guzmán Álvarez
Vigo-Spain

- Miembro del Proyecto FirebirdSQL.
- Miembro honorario de la Fundación FirebirdSQL.

http://www.firebirdsql.org

Re: [Firebird-net-provider] Feature Request: Multiple Transactions

[Willibald K. <wi...@dw...>]

Hi!

> One question in your scenario the connection is open permanently ?? ( I
> ask this because we need to think that ADO .NET is designed for work in
> disconnected mode )


Yes, of course - otherwise I could not hold the transaction open, can I?

Hmm, seems that ADO .NET supports - to me - a completely new way of working
with databases.. I've got an IBO/IBX background and therefore I'm used to
long lasting connections and 'lots' of transactions, that can be 'nested' /
concurrently started.

ADO.NET seems to favour an 'as many transactions - as many connections'
philosophy. But why do we need transaction in the first place then?! (We
could trade a connection as transaction)

?-(
 Willi

Re: [Firebird-net-provider] Feature Request: Multiple Transactions

[Willibald K. <wi...@dw...>]

> could trade a connection as transaction)

Sorry, that should have read " 'treat' a connection as.."

Re: [Firebird-net-provider] Feature Request: Multiple Transactions

[Carlos G. A. <car...@te...>]

Hello:

> But why do we need transaction in the first place then?! 

If you mean why a transaction is needed for SELECT commands, because 
firebird needs it :) , but in next version of the net provider this will 
be no needed and the net provider will start a new implicit transction 
for SELECT commands when they have no transaction.





-- 
Best regards

Carlos Guzmán Álvarez
Vigo-Spain