Board index » delphi » Delphi7 + dbExpress + Interbase6 : performance degradation

Delphi7 + dbExpress + Interbase6 : performance degradation

On Mon, 3 Mar 2003 08:42:42 +0100, "Patrick Beckers"

Quote
<patrick.beck...@rentacar.be> wrote:
>Hi,

>I've been busy rewriting the app during the weekend, it's finished now and
>it looks good. What i've done is:
>- create a second SqlConnection
>- connect every SqlDataSet that has an ExecSql to that second SqlConnection
>- wrap every ExecSql with code to start and commit a transaction

>I've been testing this and the transactions aren't stuck anymore. Today,
>we're going to do some further testing in a multiuser environment (actually
>just 2 users), but I guess this has solved our problem. The reason I didn't
>wrap the read instructions is because I've been testing with 'InTransaction'

What do you mean by "the read instruction"? Do you mean opening a CDS
to display records?

Quote
>and don't see an active transaction. Is this the correct way to check if a
>transaction is started?

If there is an active query there is an active transaction. You cannot
access data in an IB database in _any_ way without a transaction.

--
Bill (TeamB)
(TeamB cannot respond to questions received via email)

 

Re:Delphi7 + dbExpress + Interbase6 : performance degradation


You have to remember what should work in theory is not always what works
best in practice.  Ideally with IB you should have been able to
start a new transaction with a new ID and not had any issues with
anything else going on.  I have not bothered to play with this feature
because so much of the normal stuff doesn't work, why spend lot's of
time messing with advanced feature, that mostly likely don't work
too :-(

Glad the solution we recommended is working for you.

Quote
Patrick Beckers wrote:
> Hi,

> I've been busy rewriting the app during the weekend, it's finished now and
> it looks good. What i've done is:
> - create a second SqlConnection
> - connect every SqlDataSet that has an ExecSql to that second SqlConnection
> - wrap every ExecSql with code to start and commit a transaction

> I've been testing this and the transactions aren't stuck anymore. Today,
> we're going to do some further testing in a multiuser environment (actually
> just 2 users), but I guess this has solved our problem. The reason I didn't
> wrap the read instructions is because I've been testing with 'InTransaction'
> and don't see an active transaction. Is this the correct way to check if a
> transaction is started?

> Ans I want to thank everyone who participated in this thread. You're all
> most helpful.

> Patrick Beckers

> "Bill Todd" <b...@notthis.dbginc.com> schreef in bericht
> news:unvs5v07pargrl4viup0mp2f8sqhcdascd@4ax.com...

>>>>3. Reading data from the database doesn't require transactions.

>>>Yes

>>Actually, that is not correct in the case of InterBase. IB requires a
>>transaction to read data. This is a requirement of the versioning
>>architecture so you can have snapshot isolation without blocking
>>inserts or updates.

>>--
>>Bill (TeamB)
>>(TeamB cannot respond to questions received via email)

--
Thomas Miller
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://sourceforge.net/projects/dbexpressplus

Re:Delphi7 + dbExpress + Interbase6 : performance degradation


"Bill Todd" <b...@notthis.dbginc.com> schreef in bericht
news:0oj66vojtttltk012o1cvhbffvbiq7bipl@4ax.com...

Quote

> On Mon, 3 Mar 2003 08:42:42 +0100, "Patrick Beckers"
> <patrick.beck...@rentacar.be> wrote:

> >Hi,

> >I've been busy rewriting the app during the weekend, it's finished now
and
> >it looks good. What i've done is:
> >- create a second SqlConnection
> >- connect every SqlDataSet that has an ExecSql to that second
SqlConnection
> >- wrap every ExecSql with code to start and commit a transaction

> >I've been testing this and the transactions aren't stuck anymore. Today,
> >we're going to do some further testing in a multiuser environment
(actually
> >just 2 users), but I guess this has solved our problem. The reason I
didn't
> >wrap the read instructions is because I've been testing with
'InTransaction'

> What do you mean by "the read instruction"? Do you mean opening a CDS
> to display records?

No. I meant reading from a SqlDataSet (Open, First, Next, Close)

Quote

> >and don't see an active transaction. Is this the correct way to check if
a
> >transaction is started?

> If there is an active query there is an active transaction. You cannot
> access data in an IB database in _any_ way without a transaction.

Sounds fair, but when I open a SqlDataSet, read a record and then check
SqlConnection.InTransaction, it says 'false'. I'm not sure how to interprete
this, but when I manually start a transaction, SqlConnection.InTransaction
becomes 'true' until a manuel commit. Do I have to worry about it? (guess
not ;-)

- Show quoted text -

Quote
> --
> Bill (TeamB)
> (TeamB cannot respond to questions received via email)

Re:Delphi7 + dbExpress + Interbase6 : performance degradation


When dbExpress automatically creates a transaction for SELECT
or through the Provider for INSERT, UPDATE, or DELETE, it will
commit or rollback the transaction.

If you create the transaction, you are responsible for the
commit or rollback.  There is a reason it is called a transaction
_object_ :-)

It works like all the other objects in Delphi.  You create, you
destroy it.  Delphi creates it, it will destroy it.

Quote
Patrick Beckers wrote:
> "Bill Todd" <b...@notthis.dbginc.com> schreef in bericht
> news:0oj66vojtttltk012o1cvhbffvbiq7bipl@4ax.com...

>>On Mon, 3 Mar 2003 08:42:42 +0100, "Patrick Beckers"
>><patrick.beck...@rentacar.be> wrote:

>>>Hi,

>>>I've been busy rewriting the app during the weekend, it's finished now

> and

>>>it looks good. What i've done is:
>>>- create a second SqlConnection
>>>- connect every SqlDataSet that has an ExecSql to that second

> SqlConnection

>>>- wrap every ExecSql with code to start and commit a transaction

>>>I've been testing this and the transactions aren't stuck anymore. Today,
>>>we're going to do some further testing in a multiuser environment

> (actually

>>>just 2 users), but I guess this has solved our problem. The reason I

> didn't

>>>wrap the read instructions is because I've been testing with

> 'InTransaction'

>>What do you mean by "the read instruction"? Do you mean opening a CDS
>>to display records?

> No. I meant reading from a SqlDataSet (Open, First, Next, Close)

>>>and don't see an active transaction. Is this the correct way to check if

> a

>>>transaction is started?

>>If there is an active query there is an active transaction. You cannot
>>access data in an IB database in _any_ way without a transaction.

> Sounds fair, but when I open a SqlDataSet, read a record and then check
> SqlConnection.InTransaction, it says 'false'. I'm not sure how to interprete
> this, but when I manually start a transaction, SqlConnection.InTransaction
> becomes 'true' until a manuel commit. Do I have to worry about it? (guess
> not ;-)

>>--
>>Bill (TeamB)
>>(TeamB cannot respond to questions received via email)

--
Thomas Miller
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork

http://www.bss-software.com
http://sourceforge.net/projects/dbexpressplus

Re:Delphi7 + dbExpress + Interbase6 : performance degradation


Quote
>Sounds fair, but when I open a SqlDataSet, read a record and then check
>SqlConnection.InTransaction, it says 'false'. I'm not sure how to interprete
>this, but when I manually start a transaction, SqlConnection.InTransaction
>becomes 'true' until a manuel commit. Do I have to worry about it? (guess
>not ;-)

My recommendation is that when you are not using a provider and CDS
always control the transaction manually. That way you know when a
transaction is active and when it gets committed.

--
Bill (TeamB)
(TeamB cannot respond to questions received via email)

Go to page: [1] [2]

Other Threads