I think you should send the delphi program as a bug report or at least post
it on firebird-dev. Say I told you to post it there, sometimes bug reports
or questions get shooed away as if they were support requests. There's
definitely something wrong somewhere here.

Be sure to include the fb versions, especially classic or superserver. I
don't think this makes any difference thought since the problems I saw were
with superserver on linux, and windows only has superserver.

I hope we can get someone who knows the c code better to look at what is
going on.

Thanks
david jencks

On 2002.04.15 14:02:01 -0400 Marczisovszky Daniel wrote:
> >> Yes, maybe, I've also thought that. I would happily try to find this
> >> bug. Even in FB 1.0 on Linux or in FB 1.0 in Windows, because ONE OF
> >> THEM is buggy. But I'm not familiar with C/C++, even I don't know
> >> where to start. Although it seems I'm not the only one who met this
> >> problem, I'm afraid there is noone who is interested in debugging
> >> this. Only Pavel wrote a mail, and even he told this is not a bug.
>
> r> Unfortunatelly, we cannot force them to check this problem. I will
> r> try to help you in this issue.
>
> I don't want to force them, but what I made me sad is the first
> reaction was this is not a bug. I don't want to say this: come on, what a
> buggy software, I *do* really appreciate their work on this great
> project. But I believe the behaviour of the RDBMS should not depend on
> the operation system.
>
> r> What I would do first would be the rebuild of one of the native
> r> components from the source. What we need to, is to check what DPB and
> r> TPB are provided there and make them the same in driver. I made some
> r> changes in InterServer and the DPB they are using is very simple:
>
> r> isc_dpb_user_name="SYSDBA"
> r> isc_dpb_password="masterkey"
> r> isc_dpb_lc_ctype="NONE"
>
> r> I also made that changes to my sources of type 4 driver. I had no
> r> time to check the TPB of InterClient in case of
> r> TRANSACTION_READ_COMMITTED isolation.
>
> InterClient, by default, uses TRANSACTION_SERIALIZABLE which equals to
> TRANSACTION_SNAPSHOT, according to InterClient.
>
> be default Interserver initializes the TPB like this:
> *(readWriteToggle_ = parameterBlock_.next()) = isc_tpb_write;
> *(autoCommitToggle_ = parameterBlock_.next()) = isc_tpb_write;
> *(isolation1Toggle_ = parameterBlock_.next()) = isc_tpb_concurrency;
> *(isolation2Toggle_ = parameterBlock_.next()) = isc_tpb_concurrency;
> *(lockResolutionToggle_ = parameterBlock_.next()) = isc_tpb_nowait;
>
> When you change to READ_COMMITED this is what happens:
>
> *isolation1Toggle_ = isc_tpb_read_committed;
> *isolation2Toggle_ = isc_tpb_read_committed;
>
> So with a 99% of probability :) IC starts with the following TPB when
> opening a new transaction:
>
> readWriteToggle = isc_tpb_write;
> autoCommitToggle = isc_tpb_write;
> isolation1Toggle_ = isc_tpb_read_committed;
> isolation2Toggle_ = isc_tpb_read_committed;
> lockResolutionToggle = isc_tpb_nowait;
>
> r> And we have to check what is used by FIBPlus or IBX. After having
> r> exact DPB/TPB settings we can try to create a unit test for native
> r> component using only API calls. The same we should do in Java. And if
> r> the bug is there, post it to bug tracker.
>
> FIBPlus is not opensource. Moreover FIBPlus comes from IBX, since
> there a few open-source files that are almost the same IBX. I have
> debugged IBX at its lowest level, my result is:
>
> IBX uses dpb_user_name and dpb_password only.
>
> By default IBX does not start transactions with isc_start_transaction,
> but with isc_start_multiple(). The reason may be that transaction is a
> separate component in Delphi and it can be assigned to multiple
> databases. It does pass only one TPB, because I used only one
> database, but the TPB was EMPTY. It did not contain any parameter at
> all. IBX does not allow the change isolation level, although you may
> pass any isc_tpb parameter to the transaction.
>
> I'm almost sure also FIBPlus does the same. I'll contact the author of
> IBObjects, which is not free, but he is going to provide the source
> for open-source projects :)
>
> ZeosLIB uses *isc_tpb_nowait* always and
>
> itConsistency:
> begin
> TempParams.Add(isc_tpb_consistency, '');
> end;
> itConcurrency :
> begin
> TempParams.Add(isc_tpb_concurrency, '');
> end;
> itReadCommitted:
> begin
> TempParams.Add(isc_tpb_read_committed, '');
> TempParams.Add(isc_tpb_no_rec_version, '');
> end;
> itReadCommittedRec:
> begin
> TempParams.Add(isc_tpb_read_committed, '');
> TempParams.Add(isc_tpb_rec_version, '');
> end;
>
> By default ZeosLIB uses ONLY isc_tpb_nowait. If you want to use
> readcommited, etc.. you should set that, e.g. read commited is not
> used by default.
>
> ZeosLIB uses isc_start_transaction, but immediately after calling
> this, it also calls isc_start_multiple as well (unlike IBX it calls
> start_multiple always with only for one database, ZeosLIB does not
> allow you to assign a transaction to more than one database).
> The comment says this:
>
> //problem with GDS32.dll ---> ib6
> //ajouter par fourat-----> isc_start_multiple
>
> I've translated it on google, it say "added by fourat", but who knows?
> I don't speak French at all... maybe this is even not in French.
>
> Roman, if you "speak" Delphi/Pascal, I'll send any parts from these
> sources, please tell if there anything else I can do for you.
>
> r> This is quite an amount of work. Can you do this native code research
> r> (I do not have Delphi/IBX). I would do the InterClient check.
>
> >> Maybe not a bug of the Linux version, but in this case this is a
> >> bug a Windows version.
> >>
> >> I don't know if sending a bug report helps or not, but as you told I
> >> even can't decide if it is the bug of FB-Linux of FB-Windows.
>
> r> Let's try to get some more results. BTW, there was similar posting in
> r> InterClient newsgroup. I will check the replies.
>
> r> Regards,
> r> Roman
>
> Summary: these interfaces for Delphi is not so strict like Java when
> starting a new transaction. Probably this is the reason why we have
> this only in Java never with Delphi. Most of GUI tools were written in
> Delphi, that's why they work well. Probably if these Delphi softwares
> were using same TPB as Java they would have problems when managing a
> FB install on Linux. I would not be surprised if isql were not use
> that TPB that you use.
>
> I've not found yet where type 4 driver sets isc_tpb_*, but maybe we
> could do a test with no tpb at all and with isc_tpb_nowait parameter
> only.
>
> One more interesting thing:
> I've created an application in Delphi with IBX.
>
> I set the following parameters for the IBTransaction component:
> (this is what you wrote on IB-Devel, isn't it?)
>
> isc_tpb_write
> isc_tpb_concurrency
> isc_tpb_wait
>
> I've been connection to the database from my home computer to the
> database on Linux using TCP.
>
> The Delphi program produced absolutely the same results as my Java
> program, so there was absolutely no java, it's enough to set these
> three parameters for a transaction to:
>
> 1. have a deadlock when connection to a database using isql
> 2. not to update the record commited in isql.
>
> Now what? Shell I send my Delphi program as a bug report? Is it a bug
> at all? Are these parameters correct? Have not I missed anything?
>
>
> Best wishes,
> Daniel
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>