dbi-interbase-devel Mailing List for DBD::InterBase (Page 8)
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-08-28 11:59:40
|
Michael Samanov wrote:
>
> Never mind. Set $dbh->{RaiseError} = 0 and skip this message. It keeps
> silent when you tie from DBD+auth, but when you use the handle
> existent it cusses like this. Lincoln issues "LISTFIELDS" first (MySQL
> only?), then, should it fail, he tries "SELECT * FROM $table WHERE
> 0=1" and takes $sth->{NAME}. It doesn't harm though annoys.
After making some changes to Tie/DBI.pm, and run again your code sample,
I've got this silly error:
-> prepare for DBD::InterBase::db (DBI::db=HASH(0x82046e8)~0x8204670
'insert into users (pass,login) values (?,?)')
......... then ..........
out_sqlda: sqld: 0, sqln: 1. done_desc: 1.
<- prepare= DBI::st=HASH(0x821045c) at DBI.pm line 463.
-> execute for DBD::InterBase::st (DBI::st=HASH(0x821045c)~0x8204928
'test' 'joe')
dbd_bind_ph
........ and we know that this will happen:
dbd_st_execute: calling isc_dsql_execute..
ERROR EVENT -803 'Invalid insert or update value(s): object columns
are
constrained - no 2 table rows can have duplicate column values
-attempt to store duplicate value (visible to active transactions) in
unique index "USERS_I1"
' on DBI::st=HASH(0x8204928)
Invalid insert or update value(s): object columns are
constrained - no 2 table rows can have duplicate column values
-attempt to store duplicate value (visible to active transactions) in
unique index "USERS_I1"
error -803 recorded: Invalid insert or update value(s): object columns
are
constrained - no 2 table rows can have duplicate column values
-attempt to store duplicate value (visible to active transactions) in
unique index "USERS_I1"
Tie::DBI attempted to do an INSERT, instead of the expected UPDATE.
Rgds,
Edwin.
|
|
From: Michael S. <mi...@ch...> - 2000-08-28 11:48:29
|
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. Debug output without attrs: ... Decode passed. ib_dateformat: (null). Segmentation fault (core dumped) With attrs: ... Decode passed. ib_dateformat: %c. Len: 2. I didn't see much into logic and don't know why the format is not being set. Could you, please, fix it ASAP? I hope it's not hard. I think it would be the best if you set all the default attributes just in the begin of "prepare", like this: if (attribs && (svp = DBD_ATTRIB_GET_SVP(attribs, "ib_dateformat", 13)) != NULL) IB_SQLtimeformat(imp_sth->ib_dateformat, svp); else IB_SQLtimeformat(imp_sth->ib_dateformat, "%c"); It will save as from the further checkings. Here's the dirty hack attached. It fixes the current problem, but I'm not sure whether the programs will coredump at exit now. It would be fine if it didn't yet. Best regards, Michael mailto:mi...@ch... |
|
From: Edwin P. <ed....@co...> - 2000-08-28 11:08:26
|
Michael Samanov wrote: > > Hello dbi-interbase-devel, column alias now works. Changes (to dbdimp.c) have been committed. Thanks for the report. Rgds, Edwin. |
|
From: Michael S. <mi...@ch...> - 2000-08-28 07:23:10
|
Hello Edwin,
Monday, August 28, 2000, 7:46:39 AM, you wrote:
EP> I don't understand how you could proceed so far, my test fails (as I
EP> mentioned in the driver manual) on LISTFIELDS command:
Yeap, it's Tie::DBI fault. It should
{
local $dbh->{PrintError} = 0;
local $dbh->{RaiseError} = 0; # or =1 and eval
}
Never mind. Set $dbh->{RaiseError} = 0 and skip this message. It keeps
silent when you tie from DBD+auth, but when you use the handle
existent it cusses like this. Lincoln issues "LISTFIELDS" first (MySQL
only?), then, should it fail, he tries "SELECT * FROM $table WHERE
0=1" and takes $sth->{NAME}. It doesn't harm though annoys.
Best regards,
Michael mailto:mi...@ch...
|
|
From: Edwin P. <ed....@co...> - 2000-08-28 03:43:11
|
Michael Samanov wrote:
>
> Hello dbi-interbase-devel,
>
> The following script coredumps on exit (after "Ok3")
I don't understand how you could proceed so far, my test fails (as I
mentioned in the driver manual) on LISTFIELDS command:
-> prepare for DBD::InterBase::db (DBI::db=HASH(0x81ec92c)~0x81ec8b4
'LISTFIELDS users')
dbih_setup_handle(DBI::st=HASH(0x81ecba8)=>DBI::st=HASH(0x81ecb84),
DBD::InterBase::st, 81ecbb4, Null!)
dbih_make_com(DBI::db=HASH(0x81ec8b4), DBD::InterBase::st, 152)
Enter dbd_st_prepare
dbd_st_prepare: in_sqlda OK.
dbd_st_prepare: out_sqlda OK.
dbd_st_prepare: sqldialect: 3.
ib_start_transaction: transaction started.
dbd_st_prepare: statement: LISTFIELDS users.
ERROR EVENT -104 'Invalid token
-Dynamic SQL Error
-SQL error code = -104
-Token unknown - line 1, char 0
-LISTFIELDS
' on DBI::st=HASH(0x81ecba8)
InterBase SQL parser fails on that token.
Rgds,
Edwin.
|
|
From: Edwin P. <ed....@co...> - 2000-08-28 03:08:25
|
Michael Samanov wrote: > > Hello dbi-interbase-devel, > > The following script coredumps on exit (after "Ok3") > > ===================================================================================================== > use Data::Dumper; > use DBI; > use DBD::InterBase; > use Tie::DBI; > use strict; > > P.S. To Edwin: are you mind my numerous bugreports? No, keep 'em coming! :-) Maybe I can't be as responsive as before, because I've just started working on a new task (a challenging one) for my employer. I know that Tie::DBI doesn't work with the driver, it's mentioned in 'Compatibility with DBI extension modules' section in the man, but I'll try your code snippet, probably it fails on something else other than I've known. Thanks. Rgds, Edwin. |
|
From: Michael S. <mi...@ch...> - 2000-08-27 16:18:52
|
Hello dbi-interbase-devel,
The following script coredumps on exit (after "Ok3")
=====================================================================================================
use Data::Dumper;
use DBI;
use DBD::InterBase;
use Tie::DBI;
use strict;
my $db = "InterBase:database=/usr/interbase/price.gdb;host=localhost;ib_dialect=3;ib_charset=WIN1251";
my $user = 'SYSDBA';
my $pass = 'masterkey';
my $dbh = DBI->connect("DBI:$db", $user, $pass);
$dbh->trace(5);
tie my %h, 'Tie::DBI', {
db => $dbh,
# db => $db,
user => $user,
password => $pass,
table => 'users',
key => 'login',
CLOBBER => 1,
DEBUG => 1,
};
# print Data::Dumper::Dumper($h{joe});
my $pass = $h{joe}{pass};
$h{joe}{pass} = 'test';
untie %h;
print "Ok\n";
$dbh->disconnect;
print "Ok1\n";
undef %h;
print "Ok2\n";
undef $dbh;
print "Ok3\n";
1;
=====================================================================================================
CREATE DOMAIN INT_NOTNULL INT DEFAULT '0' NOT NULL;
CREATE DOMAIN SMALL_NOTNULL INT DEFAULT '0' NOT NULL;
CREATE DOMAIN CHAR1 CHAR DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR5 VARCHAR(5) DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR8 VARCHAR(8) DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR9 VARCHAR(9) DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR12 VARCHAR(12) DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR15 VARCHAR(15) DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR16 VARCHAR(16) DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR20 VARCHAR(20) DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR22 VARCHAR(22) DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR32 VARCHAR(32) DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR64 VARCHAR(64) DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR128 VARCHAR(128) DEFAULT '' NOT NULL;
CREATE DOMAIN CHAR250 VARCHAR(250) DEFAULT '' NOT NULL;
CREATE DOMAIN MONEY /*DOUBLE PRECISION*/ DECIMAL(10,2) DEFAULT '0.00' NOT NULL;
CREATE DOMAIN DATETIME TIMESTAMP DEFAULT 'NOW' NOT NULL;
CREATE DOMAIN DATE_DOM TIMESTAMP DEFAULT 'NOW' NOT NULL;
CREATE DOMAIN BAN_EVENT VARCHAR(5) DEFAULT 'load' NOT NULL
CHECK (VALUE IN ('load','click','ref'));
CREATE DOMAIN ORDER_STATE VARCHAR(8) DEFAULT '' NOT NULL
CHECK (VALUE IN ('','rejected','accepted'));
CREATE DOMAIN USER_KIND CHAR DEFAULT 'p' NOT NULL
CHECK (VALUE IN ('p','j'));
CREATE TABLE USERS (
USER_ID INT_NOTNULL,
LOGIN CHAR16,
PASS CHAR64,
REGTIME DATETIME,
KIND USER_KIND,
FNAME CHAR16,
MNAME CHAR16,
LNAME CHAR16,
PHONE CHAR16,
FAX CHAR16,
EMAIL CHAR32,
URL CHAR128,
COUNTRY CHAR16,
CITY CHAR16,
FIRM CHAR64,
INN CHAR12,
BANK CHAR64,
RS CHAR20,
KS CHAR20,
BIK CHAR9,
ADDR CHAR250,
INFO CHAR250,
CONSTRAINT USERS_PK PRIMARY KEY (USER_ID)
);
CREATE UNIQUE INDEX USERS_I1 ON USERS (LOGIN);
CREATE GENERATOR USERS_GEN;
SET TERM ^ ;
CREATE TRIGGER USERS_BEFOREINSERT FOR USERS
ACTIVE BEFORE INSERT POSITION 0
AS BEGIN
NEW.USER_ID = GEN_ID(USERS_GEN, 1);
END
^
SET TERM ; ^
==============================================================================
P.S. To Edwin: are you mind my numerous bugreports?
Best regards,
Michael mailto:mi...@ch...
|
|
From: Michael S. <mi...@ch...> - 2000-08-27 12:17:48
|
Hello dbi-interbase-devel,
my $sth = $dbh->prepare(
"SELECT GOODS_NAME || '(' || GOODS_ID || ')' AS AAA FROM GOODS");
$sth->execute;
my $h = $sth->fetchrow_hashref;
print Dumper $h;
$sth = $dbh->prepare("SELECT GOODS_NAME,GOODS_ID FROM GOODS");
$sth->execute;
my $h = $sth->fetchrow_hashref;
print Dumper $h;
prints
$VAR1 = {
'' => 'CPU Thomson 166 ST6x86P166+(1)'
};
$VAR1 = {
'GOODS_ID' => 1,
'GOODS_NAME' => 'CPU Thomson 166 ST6x86P166+'
};
Best regards,
Michael mailto:mi...@ch...
|
|
From: Michael S. <mi...@ch...> - 2000-08-26 07:57:41
|
Hello Edwin,
Friday, August 25, 2000, 6:45:46 PM, you wrote:
EP> Michael Samanov wrote:
>> Would it be bad if we could assign transaction behaviour the way, say:
>> {
>> local $dbh->{AutoCommit} = 0;
>> $sth = $dbh->prepare("...", { ib_transaction_paramXXX => YYY, ... });
>> ...
>> }
EP> Why do you think it would be bad?
EP> But, I'd rather to assign the transaction parameters to $dbh, in other
EP> words, as database handle attributes.
EP> What I have in my mind is to write a ib_set_transaction() method, to
EP> replace the SET TRANSACTION command, where users can specify the txn
EP> params. Or perhaps ib_set_transaction_params(), which should be followed
by a $dbh->>{AutoCommit} = 0 to actually start a new trans.
Aha, I see I was wrong. Transaction is not the property of the
statement (so we ought not to to set it from inside of prepare), but
the smth of DB handle. The blood will sweep away my disgrace.
It seems strange that DBI developers didn't provide the method for
setting transactions, while rollback and commit are present %-\ I see
the big ideological hole in the DBI model thus.
BTW, 0.20.6 is pretty handy and stable already. I don't know much
about memory leaks and uninitialized pointers, but now it works JUST
as I need (in contradistinction to the IBPerl based version) and don't
coredump or smth. "local $dbh->{AutoCommit}" is what I needed of.
You've done it just in time for me :-) Thanks!
Best regards,
Michael mailto:mi...@ch...
|
|
From: Michael S. <mi...@ch...> - 2000-08-26 06:02:24
|
Hello Edwin, Friday, August 25, 2000, 5:08:31 PM, you wrote: EP> ChopBlanks attrib must be used: It's ok now, thanks! Best regards, Michael mailto:mi...@ch... |
|
From: Edwin P. <ed....@co...> - 2000-08-25 14:42:40
|
Michael Samanov wrote:
> Would it be bad if we could assign transaction behaviour the way, say:
> {
> local $dbh->{AutoCommit} = 0;
> $sth = $dbh->prepare("...", { ib_transaction_paramXXX => YYY, ... });
> ...
> }
Why do you think it would be bad?
But, I'd rather to assign the transaction parameters to $dbh, in other
words, as database handle attributes.
What I have in my mind is to write a ib_set_transaction() method, to
replace the SET TRANSACTION command, where users can specify the txn
params. Or perhaps ib_set_transaction_params(), which should be followed
by a $dbh->{AutoCommit} = 0 to actually start a new trans.
Rgds,
Edwin.
>
> It's following to the Mark's suggestion (my thoughts are incredibly
> fast).
|
|
From: Michael S. <mi...@ch...> - 2000-08-25 14:19:53
|
Hello dbi-interbase-devel,
First, why it's named DBD::FAQ instead of DBD::InterBase::FAQ?
======================================================================
Q: How to get the latest value of an auto increment field?
A: $insert_id = $dbh->selectall_arrayref(
"SELECT DISTINCT(GEN_ID($field_name, 0)) FROM $table_name")->[0]->[0];
No, no, no!!! It would be more convenient if we could do this, but
generators work outside of transaction context, so the other
transaction may change the generator's value just been set by previous
SQL expression. The right answer is "SELECT field FROM table ORDER BY
field DESC" inside of the SAME (!!!) transaction or write the select
procedure like this (working example):
CREATE PROCEDURE ADD_REC
RETURNS (REC_NO INTEGER)
AS BEGIN
SELECT GEN_ID(REC_GEN, 1) FROM RDB$DATABASE INTO :REC_NO;
INSERT INTO TBL (REC_NO) VALUES (:REC_NO);
SUSPEND;
EXIT; /* redundant clause, but it never harms */
END ^
or just
CREATE PROCEDURE NEXT_RECNO
RETURNS (REC_NO INTEGER)
AS BEGIN
SELECT GEN_ID(REC_GEN, 1) FROM RDB$DATABASE INTO :REC_NO;
SUSPEND;
END
and use this value manually
========================================================================
Q: How can I perform LIMIT clause as I usually do in MySQL?
A: This can be emulated by writing a stored procedure,
although it's not as convenient to use as the LIMIT
clause. Unfortunately, direct calls to stored procedure is
not supported by the current version of DBD::InterBase.
What does it mean "calls are not supported"? Whether $dbh->do("EXECUTE
PROCEDURE proc(?,?,?)", $attr, @params) or
$dbh->selectrow_array("SELECT * FROM proc(?,?,?)", $attr, @params) do
not work? Nonsense! I just tested and it works.
========================================================================
Q: Why do placeholders fail to bind, generating unknown
datatype error message?
A: You can't bind a field name. The following example will
fail:
$sth = $dbh->prepare("SELECT (?) FROM $table");
$sth->execute('user_id');
It's not always true. Example:
my $sth = $dbh->prepare("SELECT GOODS_NAME FROM GOODS WHERE UPPER(GOODS_NAME) like UPPER(?)")
works while
$sth = $dbh->prepare("SELECT GOODS_NAME FROM GOODS
WHERE UPPER(GOODS_NAME COLLATE PXW_CYRL) like UPPER(? COLLATE PXW_CYRL)");
fails with the above error message. I don't know whether is it because
of IB parser nature or because of nature of DBD::InterBase. The
parameter meant to be some string variable like 'ps' or 'epson%1030',
never field name. BTW it works inside of the stored procedure.
Best regards,
Michael mailto:mi...@ch...
|
|
From: Michael S. <mi...@ch...> - 2000-08-25 14:19:52
|
Hello dbi-interbase-devel,
Would it be bad if we could assign transaction behaviour the way, say:
{
local $dbh->{AutoCommit} = 0;
$sth = $dbh->prepare("...", { ib_transaction_paramXXX => YYY, ... });
...
}
It's following to the Mark's suggestion (my thoughts are incredibly
fast).
Best regards,
Michael mailto:mi...@ch...
|
|
From: Edwin P. <ed....@co...> - 2000-08-25 13:05:37
|
Michael Samanov wrote:
>
> Hello dbi-interbase-devel,
>
> The new driver (0.20.6) or t/ak-dbd.t have bug: when executing
>
> Test($state or (defined($$ref[0]) && ($$ref[0] eq '')))
> or ErrMsgF("blank value returned as '%s'.\n", $$ref[0]);
>
ChopBlanks attrib must be used:
### Now, re-connect again so that we can do some more complicated
stuff..
Test($state or ($dbh = DBI->connect($test_dsn, $test_user,
$test_password, {ChopBlanks=>1})))
or ErrMsg("reconnect failed: $DBI::errstr\n");
> it shows error that value returned is filled with spaces. The error
> happens even when I change field type from CHAR(64) to VARCHAR(64).
>
No, VARCHAR is handled correctly. Try this:
$dbh = DBI->connect('dbi:InterBase:db=test.gdb', '', '',
{RaiseError =>1, ChopBlanks=>1}) or die $DBI::errstr;
$dbh->do("CREATE TABLE SAMPLE (id INTEGER, name VARCHAR(255))");
$dbh->do("INSERT INTO SAMPLE VALUES(1, 'Anything')");
$res = $dbh->selectall_arrayref("SELECT * FROM SAMPLE")->[0];
print join('|', @$res), "|\n";
$dbh->disconnect;
Rgds,
Edwin.
|
|
From: Edwin P. <ed....@co...> - 2000-08-25 12:34:59
|
Michael Samanov wrote: > > Hello dbi-interbase-devel, > > Documentation lacks description of ib_blob_read & ib_blob_write. What > should we do and what about blob cursors? ib_blob_read (for piece by piece blob read) currently is not yet implemented, or not finished. Current version treats blob read/write as if it is an ordinary data types. LongReadLen and LongTruncOk attributes are supported. Rgds, Edwin. |
|
From: Michael S. <mi...@ch...> - 2000-08-25 11:29:55
|
Hello dbi-interbase-devel, Documentation lacks description of ib_blob_read & ib_blob_write. What should we do and what about blob cursors? Best regards, Michael mailto:mi...@ch... |
|
From: Michael S. <mi...@ch...> - 2000-08-25 11:29:53
|
Hello dbi-interbase-devel,
The new driver (0.20.6) or t/ak-dbd.t have bug: when executing
Test($state or (defined($$ref[0]) && ($$ref[0] eq '')))
or ErrMsgF("blank value returned as '%s'.\n", $$ref[0]);
it shows error that value returned is filled with spaces. The error
happens even when I change field type from CHAR(64) to VARCHAR(64).
Best regards,
Michael mailto:mi...@ch...
|
|
From: Edwin P. <ed....@co...> - 2000-08-23 08:38:38
|
"Mark D. Anderson" wrote: > however, there is still zero support in this version for any kind of control > over the transactions created -- something i consider important for both > the case of AutoCommit on or off. This is sheduled for 0.22. Now for 0.21, I'm focusing on the implementation of DBI standard methods and attributes, and make sure that everything works in the right way. > These are the capabilities that caused my interest in this module to begin with. > They are critical to get good performance out of interbase. > As it is, my only reason to consider switching is if the memory corruption/leaking in IBPerl gets > too problematic. Umm, you should be able to take advantage of DBI as de-facto standard for database API in Perl :-) Rgds, Edwin. |
|
From: Mark D. A. <md...@di...> - 2000-08-22 21:32:31
|
(resending this rant for the record, now that my clock is fixed so it doesn't look
like i'm a week behind).
----- Original Message -----
From: Mark D. Anderson <md...@di...>
To: <dbi...@li...>
Sent: Monday, August 14, 2000 8:32 PM
Subject: Re: [Dbi-interbase-devel] Progress
> * starting a transaction (automatic or not) is more robust, now it
> reuses an active transaction handle, instead of overridding it with a new one,
> leaving the previous one "immortal" (because the previous transaction handle is
> no longer kept!)
however, there is still zero support in this version for any kind of control
over the transactions created -- something i consider important for both
the case of AutoCommit on or off.
in the AutoCommit=on case, the 3rd argument to your ib_start_transaction is always NULL,
so there is no way to provide it.
For example, at connect time, I'd like to provide
Dialect => 3,
Default_Transaction_Parameters => {Access => 'WRITE', Isolation => 'CONCURRENCY', Resolution => 'WAIT'}
in the AutoCommit=off case, there is no control over whether it calls isc_commit_retaining
in commit.
and there no control over the isc_start_transaction arguments in rollback.
ideally i'd like to be able to specify the Default_Transaction_Parameters at connect time, and
also change them later at any time (as i can with AutoCommit).
This would be used in for transactions created automatically, whether
AutoCommit is on or off.
I'd also like the ability create transaction objects from perl, and pass in
transactions to use, so that no transaction is created at all for me (Default_Transaction_Parameters
is irrelevant). That would allow me to maintain multiple concurrent transactions from a single
client connection.
These are the capabilities that caused my interest in this module to begin with.
They are critical to get good performance out of interbase.
As it is, my only reason to consider switching is if the memory corruption/leaking in IBPerl gets
too problematic.
Not that i'm not appreciative :).
-mda
|
|
From: Mark D. A. <md...@di...> - 2000-08-22 03:34:16
|
> * starting a transaction (automatic or not) is more robust, now it
> reuses an active transaction handle, instead of overridding it with a new one,
> leaving the previous one "immortal" (because the previous transaction handle is
> no longer kept!)
however, there is still zero support in this version for any kind of control
over the transactions created -- something i consider important for both
the case of AutoCommit on or off.
in the AutoCommit=on case, the 3rd argument to your ib_start_transaction is always NULL,
so there is no way to provide it.
For example, at connect time, I'd like to provide
Dialect => 3,
Default_Transaction_Parameters => {Access => 'WRITE', Isolation => 'CONCURRENCY', Resolution => 'WAIT'}
in the AutoCommit=off case, there is no control over whether it calls isc_commit_retaining
in commit.
and there no control over the isc_start_transaction arguments in rollback.
ideally i'd like to be able to specify the Default_Transaction_Parameters at connect time, and
also change them later at any time (as i can with AutoCommit).
This would be used in for transactions created automatically, whether
AutoCommit is on or off.
I'd also like the ability create transaction objects from perl, and pass in
transactions to use, so that no transaction is created at all for me (Default_Transaction_Parameters
is irrelevant). That would allow me to maintain multiple concurrent transactions from a single
client connection.
These are the capabilities that caused my interest in this module to begin with.
They are critical to get good performance out of interbase.
As it is, my only reason to consider switching is if the memory corruption/leaking in IBPerl gets
too problematic.
Not that i'm not appreciative :).
-mda
|
|
From: Edwin P. <ed....@co...> - 2000-08-21 16:09:18
|
"Mark D. Anderson" wrote: > > ive had no such problem; i've declared lots of foreign keys using both column constraints > and table constraints. > i think your problem is "t1.p1" is not acceptable there. > i think it has to be "t1 (p1)". this doesn't work, too. I took the example from Language Reference, page 79. I've just tried with the Classic one, only to get the same result. I'll try with the Win32 version. Beside that unknown token error, I've also had the same problem as this: http://sourceforge.net/bugs/?func=detailbug&bug_id=112340&group_id=9028 (select count() cannot be used together with other fields). Rgds, Edwin. |
|
From: Mark D. A. <md...@di...> - 2000-08-21 15:52:37
|
ive had no such problem; i've declared lots of foreign keys using both column constraints and table constraints. i think your problem is "t1.p1" is not acceptable there. i think it has to be "t1 (p1)". -mda |
|
From: Edwin P. <ed....@co...> - 2000-08-21 13:47:03
|
When testing DBIx::Abstract to work with DBD::InterBase, I've found that foreign key is an unknown token by InterBase 6.0, either the beta or the final SuperServer for Linux (I haven't tried with the Win32 version). The following fails (using isql): create table t1 (p1 integer not null primary key); create table t2 (f2 integer FOREIGN key references t1.p1 on update cascade on delete set null); Has any of you found the same problem? Rgds, Edwin. |
|
From: Edwin P. <ed....@co...> - 2000-08-21 08:06:51
|
Guys, here is the Changes list since 0.20.5: * $sth->rows() now returns the number of fetched rows, for SELECT, otherwise returns - 1 (unknown). * starting a transaction (automatic or not) is more robust, now it reuses an active transaction handle, instead of overridding it with a new one, leaving the previous one "immortal" (because the previous transaction handle is no longer kept!) * Fix $dbh->do() method for usage with placeholders. * Added support for CursorName attrib * more robust commit with AutoCommit on * Added datatype values conversion routine between InterBase internal values and DBI/ISO/ANSI/ODBC values * Fixed tables() method, now correctly removes the trailing blank spaces * Tested to 100% compliant with DBIx::Recordset ! * more informative error message * fix ping() method. Now not die if RaiseError => 1 I think I'm going to put an alpha release on CPAN next week. Now I'm working on the documentation, I'm also writing a FAQ document which is still in progress for now, you can find it on http://dbi.interbase.or.id/, any suggestion, correction are appreciated. Please let me know any problems you've found with the current version. The following TODOs are postponed for the second release: 1. implement ib_blob_read() method for piece by piece blob read. 2. Implement type_info() 3. Win32 port (anyone work on this platform?) Rgds, Edwin. |
|
From: Edwin P. <ed....@co...> - 2000-08-18 07:15:33
|
Edwin Pratomo wrote: > > > Yet other thing: I can't get working the below statement neither with > > old nor new driver. > > "SELECT ... WHERE UPPER(GOODS_NAME COLLATE PXW_CYRL) like UPPER(? COLLATE PXW_CYRL)" > > It says 2 <- prepare= undef at DBI.pm line 908. > > !! ERROR: -1 'Dynamic SQL Error > > -SQL error code = -804 > > -Data type unknown Placeholders can't be used on field names. Rgds, Edwin. |
2 messages has been excluded from this view by a project administrator.
