dbi-interbase-devel Mailing List for DBD::InterBase (Page 7)
Status: Beta
Brought to you by:
edpratomo
Menu
▾
▴
dbi-interbase-devel — Development list for DBD::InterBase
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(44) |
Sep
(33) |
Oct
(36) |
Nov
(1) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(4) |
Feb
(3) |
Mar
(2) |
Apr
(1) |
May
(4) |
Jun
(15) |
Jul
(24) |
Aug
(8) |
Sep
(4) |
Oct
(5) |
Nov
(1) |
Dec
(4) |
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(7) |
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2003 |
Jan
(1) |
Feb
|
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Edwin P. <ed....@co...> - 2000-09-27 15:15:02
|
Sorry folks for my late reply, I was off the office for the last two days. "Mark D. Anderson" wrote: > > > Commit-retaining should IMHO only be used in autocommit mode (it only > > matters in autocommit mode as commits are more infrequent in normal mode, > > so the performance hit from starting a new transcation is much smaller) > > i don't think commit_retaining should be the default behavior in either mode, > as i think i've ranted about previously in this forum :). > it has a very specialized use, when there is only a single writer for a table. > it should be an optional behavior, set at create time or commit time. I've just dropped commit_retaining. See the new InterBase.xs and dbdimp.c in the cvs repository. The changes are the improved Flemming's patch which was unsufficient (but very clear in reflecting his idea, thanks to Flemming). Let me know if there's still any problem with this. > > > * Explicit commits/rollbacks always commit_transcation / > > rollback_transaction and then end the transaction, completely. > > * any operation that needs a query should check to see if one is active > > and start one if not. > > the above is how the new dbd driver works in autocommit mode, but not how > it used to work, and it was definitely a problem. i haven't ranted as much about Is it? It would be very useful if you can reproduce the problem for me. > > I don't know if these changes would fix my immediate problem, but they are > > correct and I expect they will fix my problem. > > i've been having a variety of problems with my apache/modperl/dbi system, and > not using the old driver (which had a variety of problems, some in dbd and some > in ibperl) has now allowed me to pay attention to some database server-side problems. > > are you using SS or classic? on linux? local or remote mode? > it'd be nice to know there is someone else doing the same thing architecture as me -- most > of the discussion on the support lists is concerning all these moribund borland > fabrications like ibx/delphi/etc. the SS of IB 6.0 for _Linux_ is not supposed to use on production application. Rgds, Edwin. |
|
From: Flemming F. <di...@sw...> - 2000-09-25 20:54:37
|
"Mark D. Anderson" wrote: > > * Explicit commits/rollbacks always commit_transcation / > > rollback_transaction and then end the transaction, completely. > > * any operation that needs a query should check to see if one is active > > and start one if not. > > the above is how the new dbd driver works in autocommit mode, but not how > it used to work, and it was definitely a problem. i haven't ranted as much > about non-autocommit because i'm not using it that way. > > > I don't know if these changes would fix my immediate problem, but they are > > correct and I expect they will fix my problem. I've fixed DBD::interbase to support transactions without deadlocking all over the place, the patch against the latest CVS version is here: http://dion.swamp.dk/dbi-interbase-20000925.diff.gz The patch: * Fixes normal transaction mode (no more hanging on to stale transactions) * Does what you suggested with autocommit (no commit_retaining) * Works. The patch is in CVS here (until Ed merges it): http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/zepong/parts/DBD::InterBase/?cvsroot=zepong Please let me know if anyone finds a problem with the patch. |
|
From: Flemming F. <di...@sw...> - 2000-09-25 19:24:08
|
"Mark D. Anderson" wrote: > > * Explicit commits/rollbacks always commit_transcation / > > rollback_transaction and then end the transaction, completely. > > * any operation that needs a query should check to see if one is active > > and start one if not. > > the above is how the new dbd driver works in autocommit mode, but not how > it used to work, and it was definitely a problem. i haven't ranted as much > about non-autocommit because i'm not using it that way. > > > I don't know if these changes would fix my immediate problem, but they are > > correct and I expect they will fix my problem. Enclosed is a patch against the latest version of dbi-interbase from cvs. The patch: * Fixes normal transaction mode (no more hanging on to transactions) * Does what you suggested with autocommit (no commit_retaining) * Works. The patch is in CVS here (until Ed merges it): http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/zepong/parts/DBD::InterBase/?cvsroot=zepong Please let me know if anyone finds a problem with the patch. |
|
From: Mark D. A. <md...@di...> - 2000-09-25 15:23:10
|
> Commit-retaining should IMHO only be used in autocommit mode (it only > matters in autocommit mode as commits are more infrequent in normal mode, > so the performance hit from starting a new transcation is much smaller) i don't think commit_retaining should be the default behavior in either mode, as i think i've ranted about previously in this forum :). it has a very specialized use, when there is only a single writer for a table. it should be an optional behavior, set at create time or commit time. > > Not having an active transcation after a commit is important, or you will > have active transactions across requests (this may be a very long > time) and a newly started reuest will be working with a really > (really) old snapshot in stead of a new one. with commit_retaining, it'll be an old snapshot regardless. > > I would suggest that: > * commit_retaining should only be used for autocommit after queries. i disagree on this one. based on using other transaction parameters, there are other ways of improving the performance of these, without the usually disastrous semantics of commit_retaining. > * Explicit commits/rollbacks always commit_transcation / > rollback_transaction and then end the transaction, completely. > * any operation that needs a query should check to see if one is active > and start one if not. the above is how the new dbd driver works in autocommit mode, but not how it used to work, and it was definitely a problem. i haven't ranted as much about non-autocommit because i'm not using it that way. > I don't know if these changes would fix my immediate problem, but they are > correct and I expect they will fix my problem. i've been having a variety of problems with my apache/modperl/dbi system, and not using the old driver (which had a variety of problems, some in dbd and some in ibperl) has now allowed me to pay attention to some database server-side problems. are you using SS or classic? on linux? local or remote mode? it'd be nice to know there is someone else doing the same thing architecture as me -- most of the discussion on the support lists is concerning all these moribund borland fabrications like ibx/delphi/etc. -mda |
|
From: Flemming F. <di...@sw...> - 2000-09-25 14:01:32
|
Hiyall, I've been using DBD::InterBase in ny mod_perl application, it seems to work nicely, but when the server is loaded many apache processes start getting sigv and/or spouting "Deadlock detected" type errors. This happens both when using DBI ans well as Apache::DBI. I use InterBase to store the session data, so I start each request with a select and end it with an update. I end off my script with $dbh->commit; $dbh->disconnect; Changing the transaction isolation mode from concurrent to read_committed fixes the deadlocks right up. This workaround is wrong as I really want my transactions to be atomic. I suspect that this problem stems from the fact that all connections always have an active transcation, which IMHO is wrong, once a transaction is committed there should be *no* transaction until the next time one is needed. Commit-retaining should IMHO only be used in autocommit mode (it only matters in autocommit mode as commits are more infrequent in normal mode, so the performance hit from starting a new transcation is much smaller) Not having an active transcation after a commit is important, or you will have active transactions across requests (this may be a very long time) and a newly started reuest will be working with a really (really) old snapshot in stead of a new one. I would suggest that: * commit_retaining should only be used for autocommit after queries. * Explicit commits/rollbacks always commit_transcation / rollback_transaction and then end the transaction, completely. * any operation that needs a query should check to see if one is active and start one if not. I don't know if these changes would fix my immediate problem, but they are correct and I expect they will fix my problem. |
|
From: Mark D. A. <md...@di...> - 2000-09-25 05:30:12
|
at least in the case of generator values, it seems over aggressive in treating
integers as floats.
isql:
SQL> select GEN_ID(bscounter,0) from RDB$DATABASE;
GEN_ID
=====================
2
but with perl
my $val = $dbh->selectrow_array('select GEN_ID(bscounter,0) from RDB$DATABASE');
print $val;
i get:
2.0
dunno if this is generator-specific or not. seems like if scale is non-negative, and precision is small
enough, it should be made an int, not a float.
-mda
|
|
From: Mark D. A. <md...@di...> - 2000-09-25 03:46:58
|
any chance someone could make available a win32 binary of the DBD::InterBase, compiled for/with activestate perl? perhaps put under the anon ftp space pointed to at http://sourceforge.net/projects/dbi-interbase/ ? -mda |
|
From: Michael S. <mi...@ch...> - 2000-09-23 12:15:58
|
Hello Edwin, Saturday, September 23, 2000, 10:17:34 AM, you wrote: EP> Ummm.. seems that a bugfix release should be made available soon. 0.21 still isn't being compiled on FreeBSD. It asks for dirs, but doesn't pass -L and -I further. Please, wait one day, I'll send you the fix (or fix it by yourself). Best regards, Michael mailto:mi...@ch... |
|
From: Edwin P. <ed....@co...> - 2000-09-23 06:14:23
|
"Mark D. Anderson" wrote: > > in InterBase.pm implementation of ping(), > $sth->finish; > should be: > $sth->finish if $sth; You're correct. Ummm.. seems that a bugfix release should be made available soon. Rgds, Edwin. > > otherwise you get a fatal perl error calling a method on undef. > > -mda |
|
From: Mark D. A. <md...@di...> - 2000-09-23 05:27:05
|
in InterBase.pm implementation of ping(),
$sth->finish;
should be:
$sth->finish if $sth;
otherwise you get a fatal perl error calling a method on undef.
-mda
|
|
From: Edwin P. <ed....@co...> - 2000-09-14 22:14:03
|
I've put the patches for this at http://dbi.interbase.or.id/ Rgds, Edwin. Alexey V Drougov wrote: > > I suppose I found bug in your DBI driver for InterBase RDBMS server. > > details: > > $r = $dbh->do('delete from customer'); > # returns -2 in case I have no permission to delete from > # table named 'customer' > # it must return undef certainly > > # but if I call it this way: > > $r = $dbh->do('delete from customer where id > 0', undef, 10 ); > #it returns undef |
|
From: Edwin P. <ed....@co...> - 2000-09-11 14:32:45
|
Michael Samanov wrote: > MDA> AutoCommit off still has a clunky/limited interface, but that isn't edwin's fault, that is the > MDA> immature DBI interface that has a "commit" and "rollback" but no "begin". > > The dark issue to me. Why the damn the DBI ideologists did cover > transactions in so lamentable volume? There's one so-called "RDMS" > only in the world that happily doesn't know transactions at all - > MySQL, and, at the same time we have no standard $dbh->begin, or > $dbh->StartTrans or smth :-( Not only DBI in Perl world, see also the database API in Python world: http://www.python.org/topics/database/DatabaseAPI-2.0.html Same thing: no transaction object! Rgds, Edwin. |
|
From: Michael S. <mi...@ch...> - 2000-09-10 07:42:46
|
Hello Mark, Sunday, September 10, 2000, 5:40:18 AM, you wrote: MDA> AutoCommit off still has a clunky/limited interface, but that isn't edwin's fault, that is the MDA> immature DBI interface that has a "commit" and "rollback" but no "begin". The dark issue to me. Why the damn the DBI ideologists did cover transactions in so lamentable volume? There's one so-called "RDMS" only in the world that happily doesn't know transactions at all - MySQL, and, at the same time we have no standard $dbh->begin, or $dbh->StartTrans or smth :-( Best regards, Michael mailto:mi...@ch... |
|
From: Mark D. A. <md...@di...> - 2000-09-10 01:39:41
|
> This simply didn't cross my mind, but $tr->commit is more elegant, I
> hope, than $dbh->commit(Trans => $tr), so $tr->prepare(...)
> looks slightly shorter and clearer than $dbh->prepare(..., {Trans =>
> $tr}).
ok, but i think the non-OO api should also be available because
some rdbms's don't consider a "prepare" to be transactional, and we should
have some hope that what we do here will be a guide for other DBI drivers
to follow when adding transaction support.
indeed, i assume that interbase supports a statement being prepared
in one transaction and executed in another. it would be kind of silly
to have to re-prepare a statement for every transaction using it; i usually
prepare all my statements at program startup time.
>
> BTW, it $dbh and $sth seem to have the method or the property
> returning the current transaction. Smth like $dbh->tr or
> $dbh->{Trans}.
I'd rather call it "default transaction" than "current transaction".
Also, it should be recognized/documented that $dhb->DefaultTrans() may return null
(when autocommit on and a commit or finish has been done; or when autocommit is
off and explicit transactions are always used.)
One of the things I'm glad that edwin has cleaned up in his re-write is that in AutoCommit=on,
the default transaction exists only on demand (as opposed to the previous approach of
always starting one when the previous one commits).
This is a good step towards allowing a user-specified transaction handle or transaction
parameters regardless of the AutoCommit setting.
AutoCommit off still has a clunky/limited interface, but that isn't edwin's fault, that is the
immature DBI interface that has a "commit" and "rollback" but no "begin".
(btw, I am still hoping that i can convince edwin to not do isc_commit_retaining in commit()
by default, but instead to make that behavior an option -- combined with the default transaction
parameter of snapshot isolation, it would generally have bad effects with multiple writers.)
How is this as a summary of what we might do:
1. Allow specifying the transaction parameters that should be used when the driver creates
any default transaction on behalf of the programmer. This would be done by setting
the option DefaultTransParams, which can be specified at connect() time, or by setting
$dbh->{DefaultTransParams} later. The value can be a string or a hash.
Unlike the case of changing the value of AutoCommit, changing DefaultTransParam
has *no* affect on the current transaction, only on the next one made.
2. Allow creating a transaction handle, via $trh = $dbh->BeginTrans({%options})
3. Allow specifying the transaction handle to use on any $dbh method, by adding a
{%options} argument at the end; one of the options can be Trans => $trh.
4. Allow the same options argument for certain $sth methods: execute() and do().
Note that if someone does $sth = $dbh->prepare($stmt, {Trans => $trh}),
then $trh is used as the default transaction for all methods on the $sth -- *unless* the
programmer specifies a Trans option for execute() or do(), which means that
a different txn is used for the two steps.
5. Support (3) to be done in an OO way, so that $dbh->whatever(..., {Trans => $trh, %options})
is the same as $trh->whatever(...,{%options}).
Note that:
(i) I am not suggesting that (4) be done OO: $trh->execute() would imply a concept
of a "current statement" for a transaction, or some such messiness.
(ii) Despite what I may have posted earlier, I am not suggesting that we support
a "TransParams" option that sets the transaction parameters for the default transaction
for just this operation. The programmer must either set DefaultTransParams, which
affects all future default transactions created, or must provide a Trans, which is a transaction
handle created how she likes.
(iii) I am also not suggesting a the ability to set a DefaultTrans, only set DefaultTransParams.
The value of DefaultTrans can be read, not written. It is always something allocated
automatically within the driver, if it exists at all. Its allocation/deallocation is managed
within the driver.
> The one issue else: what must we do with transaction on it's
> destroying? If it's enough just commit or rollback, maybe the
> parameter named, say, AutoCommit will be useful.
I think a different option should be used, such as 'FinishAction'.
So a person could specify $trh->{FinishAction} = 'commit', 'rollback', 'abandon', 'error'.
The FinishAction could also be specified as an option when creating the transaction, as in
$dbh->BeginTrans({FinishAction => 'commit'}).
'commit' means call $trh->commit() automatically.
'rollback' means call $trh->rollback() automatically.
'abandon' means "do not call any rdbms operations automatically, just free your memory"
(this is because some rdbms's treat this differently -- believe that a in interbase, explicitly
aborted transactions take up space over time, while merely abandoned ones do not.)
'error' means to die or set err, according to RaiseError.
The default would be 'error'.
> MDA> You actually have two proposals above -- one on how to specify parameters,
> MDA> and one on how to change the api.
>
> Thank you, your words sound like nectar and ambrosia taste :-)
How can i live up to that? :)
-mda
|
|
From: Michael S. <mi...@ch...> - 2000-09-09 17:12:14
|
Hello Mark,
Saturday, September 09, 2000, 6:35:18 PM, you wrote:
MDA> i don't think it should be called "tr", to distinguish it from a
MDA> transaction handle -- these are just transaction parameters.
MDA> could be "TransParams" or something.
That definitely would be better. My suggestion was only draft.
>> $tr = $dbh->begin(\%params).
MDA> there will always be other options, and for symmetry, i think this should be:
MDA> begin({TransParams => \%params});
Very reasonable, too.
>> This transaction object has the same methods as $dbh has, i.e.
>> prepare, execute, selectrow_array and others.
MDA> What I would like is for the methods to all support a {Trans => $tr} or {TransParams => $string}
or {TransParams =>> $hash} in their options argument.
MDA> In other words, i don't see a need to make the transaction handle also be
MDA> an object with methods, though I suppose it couldn't hurt.
This simply didn't cross my mind, but $tr->commit is more elegant, I
hope, than $dbh->commit(Trans => $tr), so $tr->prepare(...)
looks slightly shorter and clearer than $dbh->prepare(..., {Trans =>
$tr}).
BTW, it $dbh and $sth seem to have the method or the property
returning the current transaction. Smth like $dbh->tr or
$dbh->{Trans}.
The one issue else: what must we do with transaction on it's
destroying? If it's enough just commit or rollback, maybe the
parameter named, say, AutoCommit will be useful.
MDA> You actually have two proposals above -- one on how to specify parameters,
MDA> and one on how to change the api.
Thank you, your words sound like nectar and ambrosia taste :-)
MDA> Both seem fine to me, but in the end it is Edwin who rules....
I don't think anybody will refuse the working improvements :-)
Best regards,
Michael mailto:mi...@ch...
|
|
From: Mark D. A. <md...@di...> - 2000-09-09 14:33:25
|
> What do you think about my suggestion? I offered the following:
>
> Any database connection has the default transaction that is controlled
> by AutoCommit attribute and by the additional attributes of "prepare",
> "do" and the like methods.
> $sth = $dbh->prepare("select ...", { tr => \%params });
fine with me. the code could be smart, and if tr is a scalar, parse it as SET TRANSACTION,
and if it is a hash, deal with it as, um, a hash.
i don't think it should be called "tr", to distinguish it from a transaction handle --
these are just transaction parameters.
could be "TransParams" or something.
>
> Besides that the user may assign as many named transactions as he (we
> Russuan call user ALWAYS "he" ;-) ) likes by the syntax:
> $tr = $dbh->begin(\%params).
there will always be other options, and for symmetry, i think this should be:
begin({TransParams => \%params});
>
> This transaction object has the same methods as $dbh has, i.e.
> prepare, execute, selectrow_array and others.
What I would like is for the methods to all support a {Trans => $tr} or {TransParams => $string}
or {TransParams => $hash} in their options argument.
In other words, i don't see a need to make the transaction handle also be
an object with methods, though I suppose it couldn't hurt.
> This model doesn't conflict with "SET TRANSACTION" syntax because the
> parameters can be named the same, so you need not to develop your own
> documentation.
> I would like this, but you, of course, may disallow it, and I would do
> nothing with it but to resent and to write my transactions by my own
> :-)
You actually have two proposals above -- one on how to specify parameters,
and one on how to change the api. Both seem fine to me, but in the end it
is Edwin who rules....
-mda
|
|
From: Michael S. <mi...@ch...> - 2000-09-09 06:52:00
|
Hello Mark,
Friday, September 08, 2000, 2:57:56 AM, you wrote:
MDA> i know where you are coming from; i waffled back and forth while writing it.
MDA> in the end, i decided to use the exact naming and syntax of the SET TRANSACTION
MDA> statement in interbase embedded sql, because it obviates the need for
MDA> extended documentation. i've learned not to underestimate the pain of
MDA> deviating needlessly from an already-documented interface.
MDA> unfortunately, those keywords don't map particularly well to the underlying isc C api,
MDA> nor to traditional transactional theory, which bothers me too.
MDA> of course, we could accept both, i suppose...
What do you think about my suggestion? I offered the following:
Any database connection has the default transaction that is controlled
by AutoCommit attribute and by the additional attributes of "prepare",
"do" and the like methods.
$sth = $dbh->prepare("select ...", { tr => \%params });
Besides that the user may assign as many named transactions as he (we
Russuan call user ALWAYS "he" ;-) ) likes by the syntax:
$tr = $dbh->begin(\%params).
This transaction object has the same methods as $dbh has, i.e.
prepare, execute, selectrow_array and others.
This model doesn't conflict with "SET TRANSACTION" syntax because the
parameters can be named the same, so you need not to develop your own
documentation. So,
$tr = - $dbh->begin({
write => 1,
wait => 0,
isolation => 'snapshot',
using => [$dbh1, $dbh2],
reserving => [
{
shared => 1,
write => 0,
names => [qw(table1 table2)],
},
{
shared => 0,
write => 1,
names => [qw(table3 table4)],
}
]
});
I would like this, but you, of course, may disallow it, and I would do
nothing with it but to resent and to write my transactions by my own
:-)
Best regards,
Michael mailto:mi...@ch...
|
|
From: Mark D. A. <md...@di...> - 2000-09-07 23:00:20
|
>I'll probably make some changes on the interface (for the > transaction params). i know where you are coming from; i waffled back and forth while writing it. in the end, i decided to use the exact naming and syntax of the SET TRANSACTION statement in interbase embedded sql, because it obviates the need for extended documentation. i've learned not to underestimate the pain of deviating needlessly from an already-documented interface. unfortunately, those keywords don't map particularly well to the underlying isc C api, nor to traditional transactional theory, which bothers me too. of course, we could accept both, i suppose... -mda |
|
From: Edwin P. <ed....@co...> - 2000-09-07 17:03:12
|
I've just put 0.21 alpha both on CPAN and sourceforge. But I forgot to make a minor change to dbdimp.h, where I should have removed the malloc.h. This causes gcc to issue an annoying warning when compiling on FreeBSD, as Michael reported to me. :-( I've also received a patch from Mark which introduces a mechanism for transaction control. I haven't enough time to fully test it, so it's not in this release. But this won't take long time to reach the CVS repository. I'll probably make some changes on the interface (for the transaction params). Rgds, Edwin. |
|
From: Mark D. A. <md...@di...> - 2000-09-02 22:43:24
|
i couldn't wait, so i did it myself.
attached is a complete copy of a modified dbdimp.c, a diff relative to 20.6, and a small test program.
i don't know if the attachments will have windows line endings or unix, but
presumably you can deal with that.
(i didn't know what sort of diff parameters you'd like, which is why i sent the whole thing; sorry).
there are a few issues to take care of (marked by "XXX" in the source), but it basically works.
you can say:
$dbh->{TPB} = 'NO WAIT SNAPSHOT TABLE STABILITY';
and then the next transaction allocated by the driver (automatic if autocommit)
will use those attributes instead of the default ones.
you can also specify TPB as one of the attributes in the DBI->connect() call, as shown
in the test program.
The strings accepted for the TPB key are identical to the ones documented in the EmbedSQL guide.
sorry, i didn't write the test using the conventions in the "t/" directory, because that directory
is incomprehensible to me.
this change fixes a leak as a side-effect (the previous version was leaking a copy of tpb_buffer
on every transaction).
two issues not related to this checkin:
1. $VERSION in InterBase.pm should be updated every time you make a release.
2. i still think that the hard-coded isc_commit_retaining behavior when autocommit
is off is a very bad idea, but since i'm using autocommit on, i left it there in this patch.
-mda
|
|
From: Michael S. <mi...@ch...> - 2000-08-30 21:07:48
|
Hello dbi-interbase-devel, I was playing today with Delphi && FreeIBComponents, so there are separate object - transaction (TFIBTransaction). It's seen thus that there may be multiple transactions per connection in Interbase. So I thought, there had to be the single default transaction (DBI notion) and smth like # start new transaction $tr = $dbh->begin( \%params ); # prepare in the named transaction's context $sth1 = $tr->prepare(...); # prepare in the default transaction's context $sth2 = $dbh->prepare(...); ... $tr->commit; $dbh->rollback; So for the rest of the methods. Best regards, Michael mailto:mi...@ch... |
|
From: Edwin P. <ed....@co...> - 2000-08-30 12:30:28
|
Good news, DBD::InterBase works with DBIx::Tree.
Due to a small bug in DBI.pm, this patch must be applied first.
Rgds,
Edwin.
Edwin Pratomo wrote:
>
> >From DBI 1.14 doc:
>
> When passed a hash reference, fetchall_arrayref uses
> the fetchrow_hashref entry elsewhere in this
> documentto fetch each row as a hash reference. If the
> parameter hash is not empty, then it is used as a
> slice to select individual columns by name. The names
> should be lower case regardless of the letter case in
> $sth->{NAME}. The values of the hash should be set to
> 1.
>
> .......
> To fetch all fields of every row as a hash ref:
>
> $tbl_ary_ref = $sth->fetchall_arrayref({});
>
> In reality, when passed an _empty_hash_ref_ as the above snippet, the
> column names' letter case depend on the underlying database, in other
> words, they are the same as what is stored in $sth->{NAME}.
>
> Attached is the fix.
>
> Rgds,
> Edwin.
> |
|
From: Michael S. <mi...@ch...> - 2000-08-28 17:42:39
|
Hello Edwin,
Monday, August 28, 2000, 4:03:22 PM, you wrote:
EP> Tie::DBI attempted to do an INSERT, instead of the expected UPDATE.
Tie::DBI contains the bug:
sub EXISTS {
my ($s,$key) = @_;
$key = $s->_quote($s->{key},$key) unless $s->{CanBindSelect};
my $st = $s->_run_query('fetch1',"SELECT $s->{key} FROM $s->{table} WHERE $s->{key} = ?",$key);
croak $DBI::errstr unless $st;
$st->fetch;
my $rows = $st->rows;
$st->finish;
$rows != 0;
}
The last line should be changed with $rows > 0, and no matter, as your
driver doesn't return proper rows value, Tie::DBI won't work.
Best regards,
Michael mailto:mi...@ch...
|
|
From: Michael S. <mi...@ch...> - 2000-08-28 17:42:39
|
Hello Edwin,
Monday, August 28, 2000, 5:03:55 PM, you wrote:
>> When $dbh->trace(5) it cannot find ib_dateformat and dumps. When I
>> set pass it as attribute for $sth->prepare, it works.
EP> Could you send me your script that shows this problem?
All the genial are always simple.
==============================================================
use DBI;
use DBD::InterBase;
use strict;
my $db = "DBI:InterBase:database=/usr/interbase/price.gdb;host=localhost;ib_dialect=3;ib_charset=WIN1251";
my $user = 'WWW';
my $pass = 'www';
my $dbh = DBI->connect($db,$user,$pass,{'RaiseError' => 1}) or die DBI->errstr;
$dbh->trace(5);
my $sth = $dbh->prepare("SELECT * FROM USERS");
$sth->execute;
my $h = $sth->fetchrow_hashref;
1;
==============================================================
The table structure you have yet.
EP> I won't use the previous Tie::DBI script because it absolutely doesn't
EP> work.
Here's the diff to Tie::DBI.pm. It got away from my head completely
that I patched it. The original module can't work at all.
EP> I personally never set the trace level to 5, because the most verbose
EP> debug message I print is at trace level 4.
Level 5 is just in case :-)
>> I think it would be the best if you set all the default attributes
>> just in the begin of "prepare", like this:
EP> Only if necessary. I let the attributes initialized to NULL, and set
EP> them only when any of the output fields needs them.
Maybe it's better...
Best regards,
Michael mailto:mi...@ch... |
|
From: Edwin P. <ed....@co...> - 2000-08-28 13:00:15
|
Michael Samanov wrote: > > Hello Edwin, > > %subj%!!!!!!!!!!!!! > > When $dbh->trace(5) it cannot find ib_dateformat and dumps. When I set > pass it as attribute for $sth->prepare, it works. Could you send me your script that shows this problem? I won't use the previous Tie::DBI script because it absolutely doesn't work. I personally never set the trace level to 5, because the most verbose debug message I print is at trace level 4. > > I think it would be the best if you set all the default attributes > just in the begin of "prepare", like this: Only if necessary. I let the attributes initialized to NULL, and set them only when any of the output fields needs them. Rgds, Edwin. |
2 messages has been excluded from this view by a project administrator.
