dbi-interbase-devel Mailing List for DBD::InterBase (Page 5)
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: Enrique I.R. <es...@id...> - 2000-11-18 22:32:28
|
Hi. I wanna know the corresponding domain a fieldname is through DBD::Interbase. That is, the same info you get doing a 'show table' into interbase's isql. I tryed using $sth->table_info but didn't catch any success. Any idea? |
|
From: Enrique I.R. <es...@id...> - 2000-10-26 08:57:44
|
I'm trying to get a list of the tables/views of my DB through table_info() but I only get all the tables on it but duplicated. That is: NAME TYPE table1 table table2 table table1 view table2 view But I do not get any view of my DB (there are, I sure you). Any idea to get a list of the views of my DB through DBI. |
|
From: Mike K. <mi...@ma...> - 2000-10-16 01:40:35
|
Hi, Has anyone built an Active State version of IBPerl ? I would really like to get one, but do not have the necessary MS compilers to build it myself. Any help would be appreciated. Cheers Mike |
|
From: Edwin P. <ed....@co...> - 2000-10-14 00:00:58
|
"Enrique I.Rodriguez" wrote: > > Anyway to access interbase metadata through DBI queries?. > > I say, the same info you get with isql's show commands. I know you go > > The same question... Anyway to do 'show' commands through interbase > DBI? $dbh->table_info(). But still not as detail as the isql's show table. Rgds, Edwin. |
|
From: Flemming F. <di...@sw...> - 2000-10-13 16:21:41
|
"Mark D. Anderson" wrote: > why sap instead of postgres? Well, sap_db is: * set to be released under GPL soon, * it is supported by SAP AG with around 100 people. * I think it's pretty fast * scaleable (it can support SAP/R3) * Has every feature I have ever wanted. * DBI driver written by SAP (so it actually works;) The thing just feels good. > when i crack and abandon interbase, pg is the one i was going to go > to next.... I've tried postgresql in the past, but it has it's own set of strange problems, but I guess it is as mush a wish to try something else as any thing else. |
|
From: Mark D. A. <md...@di...> - 2000-10-13 15:32:18
|
>The DMBS (6.0 SS, Linux) seems to leak memory at an alarming rate and has >started to report "database file seems corrupt"-type errors in the >errorlog. i've definitely seen the leaking. seems related to inserts. corruption i've only seen when i mistakenly ran classic and SS simultaneously against the same gdb file. > I've tried exchanging the SS for Classic (local mode), performance was > much much higher, but it seemed to deadlock (with no processes using CPU) > even at really really light loads. exactly my experience. i attached in a debugger and got the full stack trace; it was a hang in semop(). we have paid support to ibphoenix and they are looking at it, but it has the feel of the kind of thing that won't get fixed any time soon. > What gives? has InterBase rotted through? what must one do to get a > reliable Interbase? i've been disappointed too. i expected more from a product that has been around so long. my guess is that the SS code base is still not stable (i don't trust any fresh MT code), and the classic has not had enough soak time on linux. > > Anyway, I'm going to attempt to port everything to sap db this weekend, as > SAP/R3 has over 16000 tables I hope this DBMS will work, but I'm a bit sad > leaving IB. why sap instead of postgres? when i crack and abandon interbase, pg is the one i was going to go to next.... -mda |
|
From: Enrique I.R. <es...@id...> - 2000-10-13 15:14:42
|
Anyway to access interbase metadata through DBI queries?. I say, the same info you get with isql's show commands. I know you go through the system tables but this seems a bit obtuse and inflexible method. The same question... Anyway to do 'show' commands through interbase DBI? |
|
From: Flemming F. <di...@sw...> - 2000-10-13 12:20:15
|
Hi, I've been using interbase for a while now and I'm starting to become a bit disappointed with the quality of the server as well as the dbd. The DBD seems to, Deadlock, segfault, fail during ping() and then segfault. The DMBS (6.0 SS, Linux) seems to leak memory at an alarming rate and has started to report "database file seems corrupt"-type errors in the errorlog. I've tried exchanging the SS for Classic (local mode), performance was much much higher, but it seemed to deadlock (with no processes using CPU) even at really really light loads. What gives? has InterBase rotted through? what must one do to get a reliable Interbase? Anyway, I'm going to attempt to port everything to sap db this weekend, as SAP/R3 has over 16000 tables I hope this DBMS will work, but I'm a bit sad leaving IB. |
|
From: Mark D. A. <md...@di...> - 2000-10-11 03:48:49
|
maybe this is fixed in Michael's patch, i dunno:
Name "main::choice" used only once: possible typo at Makefile.PL line 33.
Using DBI 1.13 installed in /home/buildsite/local/perl-5.6.0/lib/site_perl/5.6.0/i686-linux/auto/DBI
Interbase installation directory:
2) /opt/interbase
9) other
Your choice: 2
Where is your InterBase include directory? [/opt/interbase/include]
Where is your InterBase library directory? [/opt/interbase/lib]
First of all, line 33 is really suspicious:
my $choice = prompt("Your choice:", $choice);
And second of all, if there is exactly one of the hardcoded choices found (i.e. keys(%dirs) == 2),
then i don't want any questions.
-mda
|
|
From: Edwin P. <ed....@co...> - 2000-10-09 20:40:23
|
"Mark D. Anderson" wrote: > > (in case you are wondering about the time warp; so am i; > fyi i posted this message sept 2; beats me why i'm now getting a copy on oct 5.) Several days ago, I received a message from Flemming which told me where I was wrong so I couldn't get into this list admin page. Rgds, Edwin. |
|
From: Mark D. A. <md...@di...> - 2000-10-09 19:56:41
|
(in case you are wondering about the time warp; so am i; fyi i posted this message sept 2; beats me why i'm now getting a copy on oct 5.) note that since i wrote this, i'm now thinking a revised/expanded ui would be better, along the lines resulting between the exchange between me and Michael Samanov: http://www.geocrawler.com/archives/3/5201/2000/9/0/4318754/ -mda ----- Original Message ----- From: Mark D. Anderson <md...@di...> To: <dbi...@li...> Sent: Saturday, September 02, 2000 3:41 PM Subject: [Dbi-interbase-devel] support for transaction parameters > i couldn't wait, so i did it myself. |
|
From: Michael S. <mi...@ch...> - 2000-10-07 18:19:42
|
Hello Edwin, Friday, October 06, 2000, 4:00:52 PM, you wrote: >> > I'm not thinking it's a deal of SS or classic server: you are client >> > and it is server, and you are both different processes communicating >> > via TCP/IP. If IBPerl code shows the same problem then it means that >> > some leakage is in the Interbase client library - gds.a (or, more >> > likely, gds.so). EP> Silly question: where is the libgds.a? The silly answer as well: in FreeBSD :-) Best regards, Michael mailto:mi...@ch... |
|
From: Michael S. <mi...@ch...> - 2000-10-07 18:19:38
|
Hello Edwin, Friday, October 06, 2000, 8:26:21 PM, you wrote: >> Use FreeBSD version of IB, it contains static library, along with >> dynamic :-) BTW, what's wrong in dynamic linking? And, in any case, EP> The MTAs requires static client library to use the related DBMS for EP> users database. Hmmm, it's strange for me. I've always been thinking that there wasn't difference between static and dynamic linking in the sense of execution %-\ Whether 'ld' doesn't try to do it's best when it choose the type of binding? Best regards, Michael mailto:mi...@ch... |
|
From: Edwin P. <ed....@co...> - 2000-10-06 17:46:30
|
Jon Barker wrote: > > >From the log file created by leak.pl, we can see how the ibserver > > process growing. comparing the top_autocommit_1.txt and > > top_autocommit_2.txt, seems a bit confusing. the second log shows a > > fixed size increment of 4 KB at every 16304 loop (what is this > > mysterious number?), after the first increment at the 12349-th loop. > > After repeating the test many times, I see that ibserver starts growing > > after the 10000-th loop. > > I don't get a growing server, it's the client process that grows? > I always use a server over a network connection though, so it maybe Oh no, we were talking about different creatures.. :-( When reading your previous posting, I quickly thought that probably I forgot to free some handle in the driver that causes the ibserver to grow, so I paid attention to the ibserver size! doooh... :-( Also, I was attracted by the huge number of loops you're using in your test case which coincidentally important in my result. > that is what makes the difference. > I tweaked your leak.pl to highlight it (attached) it also expands > by 4096, I guess the page size of the system, but the number of > iterations is much lower. Ya I see it now... why I didn't notice this before? :-( Rgds, Edwin. |
|
From: Edwin P. <ed....@co...> - 2000-10-06 16:23:31
|
Michael Samanov wrote: > > Hello Edwin, > > Friday, October 06, 2000, 3:02:44 PM, you wrote: > > EP> I'm busy with a project for my employer. Of course I'd like to use > EP> DBD::InterBase for this project which uses mod_perl and Apache::DBI, but > EP> I don't know any availability of a static version of libgds :-( > EP> I do really need this for linking with an MTA, such as postfix or qmail. > EP> MySQL and PostgreSQL have such libraries. > > Use FreeBSD version of IB, it contains static library, along with > dynamic :-) BTW, what's wrong in dynamic linking? And, in any case, The MTAs requires static client library to use the related DBMS for users database. > you have the full access to the sources, can't you build the library > by yourself? Yeah, I've thought of this before, but I remembered the build instruction posted by Mark O'Donoghue to the ib-build list about July 30 which is turtuous and seems painful. Btw, I'm downloading the latest firebird's tarball now, I hope the build procedure has far improved since that dark age :-) Rgds, Edwin. |
|
From: Jon B. <jon...@ca...> - 2000-10-06 16:15:34
|
> My conclusion is the problem is not in the driver (I dont know about > IBPerl, haven't taken a closer look at that), because the _same_ > behaviour is also observed when directly using InterBase's DSQL_API, > with the same logic flow as in the driver. > My leak.c works like the driver in AutoCommit on, and noauto.c works > like in AutoCommit off. I tried messing around with dsql to see if it was the gds lib = that was leaking, I altered api3 in the interbase/examples = to do a repeated execute & fetch and the client did not = leak. It maybe that I've made a mistake somewhere in = it however, I'm not very familiar with coding database = stuff in C but it does appear to work. I've attached it anyway maybe it'll shine some light on the problem. = > >From the log file created by leak.pl, we can see how the ibserver > process growing. comparing the top_autocommit_1.txt and > top_autocommit_2.txt, seems a bit confusing. the second log shows a > fixed size increment of 4 KB at every 16304 loop (what is this > mysterious number?), after the first increment at the 12349-th loop. = > After repeating the test many times, I see that ibserver starts growing= > after the 10000-th loop. = I don't get a growing server, it's the client process that grows? = I always use a server over a network connection though, so it maybe = that is what makes the difference. I tweaked your leak.pl to highlight it (attached) it also expands = by 4096, I guess the page size of the system, but the number of = iterations is much lower. Thanks, Jon Barker |
|
From: Michael S. <mi...@ch...> - 2000-10-06 15:01:08
|
Hello Edwin, Friday, October 06, 2000, 3:02:44 PM, you wrote: EP> I'm busy with a project for my employer. Of course I'd like to use EP> DBD::InterBase for this project which uses mod_perl and Apache::DBI, but EP> I don't know any availability of a static version of libgds :-( EP> I do really need this for linking with an MTA, such as postfix or qmail. EP> MySQL and PostgreSQL have such libraries. Use FreeBSD version of IB, it contains static library, along with dynamic :-) BTW, what's wrong in dynamic linking? And, in any case, you have the full access to the sources, can't you build the library by yourself? Best regards, Michael mailto:mi...@ch... |
|
From: Edwin P. <ed....@co...> - 2000-10-06 12:04:26
|
Michael Samanov wrote: > EP> - Makefile.PL now works for FreeBSD (Michael Samanov), as the result, > EP> it's now a bit unfriendly for Linux users (!) :-) but this shouldn't be > EP> a big problem, just remember that IB 6.0 for Linux's libgds resides in > EP> /usr/lib > > Here's the improved variant. I wrote the *GREATEST* :-) function that > tests the locations and it seems like it founds all the dirs almost by > itself. I hoped, I enumerated the whole set of the paths, if I didn't, > it could be corrected easily. > > The patch is to be applied to 0.21.1. Thanks Michael, it's already committed. Rgds, Edwin. |
|
From: Edwin P. <ed....@co...> - 2000-10-06 11:58:12
|
Edwin Pratomo wrote: > > Michael Samanov wrote: > > > > > I'm not thinking it's a deal of SS or classic server: you are client > > and it is server, and you are both different processes communicating > > via TCP/IP. If IBPerl code shows the same problem then it means that > > some leakage is in the Interbase client library - gds.a (or, more > > likely, gds.so). Silly question: where is the libgds.a? > > I've just tried this test using DSQL C API, and it seems that _both_ > drivers, mine and IBPerl has leaks. ^^^^^^^^ whoops, IBPerl is not a driver. sorry. > For now I haven't found where exactly it leaks. Need investigate this > further. > After spending hours observing this behavior, finally I've located the problem. I've attached the test sources and the result files as well for you to see. My conclusion is the problem is not in the driver (I dont know about IBPerl, haven't taken a closer look at that), because the _same_ behaviour is also observed when directly using InterBase's DSQL_API, with the same logic flow as in the driver. My leak.c works like the driver in AutoCommit on, and noauto.c works like in AutoCommit off. From the log file created by leak.pl, we can see how the ibserver process growing. comparing the top_autocommit_1.txt and top_autocommit_2.txt, seems a bit confusing. the second log shows a fixed size increment of 4 KB at every 16304 loop (what is this mysterious number?), after the first increment at the 12349-th loop. After repeating the test many times, I see that ibserver starts growing after the 10000-th loop. The size is restored after disconnection. So we may encountered serious problem if we are running DBD::InterBase or more exactly, any client, in a persistent database connection such as Apache::DBI if we make such loops (more than 10000 loops) many times, before the connection is disconected (and reconnected) due to timeout. Rgds, Edwin. > > > I just have tested - FreeBSD has the same problem. > > |
|
From: Edwin P. <ed....@co...> - 2000-10-06 10:59:57
|
Flemming Frandsen wrote: > > I think that you have to be in a situation where you prepare a statement > after some memory has been used and free()'ed to run into the this bug, > I can reproduce it pretty reliably by now. > > BTW, the bugfix is pretty straight forward, (see below), so I have no > idea why ed hasn't included it yet, maybe he's off on vacation or > something? I'm still here, R/O mode :-) I'm busy with a project for my employer. Of course I'd like to use DBD::InterBase for this project which uses mod_perl and Apache::DBI, but I don't know any availability of a static version of libgds :-( I do really need this for linking with an MTA, such as postfix or qmail. MySQL and PostgreSQL have such libraries. > > > though i wrote that patch DBD::InterBase to do that, i haven't integrated it into our > > production system and probably won't til it is clear what edwin will do with it; i > > don't want to be reliant on a fork. Your patch is ok, I don't see any reason to refuse it. but now let's solidify the current code first. > We are running on a fork, edwins version is too buggy (at the moment > anyway) I'd like to see any improvement you've made so we don't have to keep up with two (or worse, more!) different versions. Rgds, Edwin. |
|
From: Edwin P. <ed....@co...> - 2000-10-06 10:45:28
|
Flemming Frandsen wrote:
>
> Ok, I managed to get a stacktrace out of the dying apache and I've been
> tinkering with it a bit tonight, the short story is:
>
> I found the bug and iced it (yay!).
>
> The sqlda needs to be zeroed before using it:
> (hint: the memset line is new)
>
> #define IB_alloc_sqlda(sqlda, n) \
> { \
> short len = n; \
> if (sqlda) { \
> safefree(sqlda);sqlda = NULL; \
> } \
> if (!(sqlda = (XSQLDA*) safemalloc(XSQLDA_LENGTH(len)))) { \
> do_error(sth, 2, "Fail to allocate XSQLDA"); \
> } \
> memset(sqlda,0,XSQLDA_LENGTH(len)); \
Thanks, Flemming. Changes have been committed.
> Ed: Could you *please* change the mailing list settings to "reply to
> list"?
I'd like to, but I don't know how. The project admin always lead me to
http://lists.sourceforge.net/mailman/admin/dbi-interbase-devel
where I am supposed to enter a password, which is not the same as my
sourceforge's password. And as I remember, I've never set any password
for the mailman :-(
>
> BTW is there ANY good reason for this to be a macro in stead of a
> function?
There's no special reason. One can write a function which accepts the
address of sqlda and does the same thing.
And there's still the ordinary reason, macro is faster because there's
no stack operation such that in function.
Rgds,
Edwin.
|
|
From: Michael S. <mi...@ch...> - 2000-10-04 20:05:51
|
Hello Flemming, Wednesday, October 04, 2000, 8:41:19 PM, you wrote: FF> How do you know what id the generator made up for you? You may, for example, 'select gen_id(field_gen, 1) from rdb$database'. It will be unique garanteed. It depends of no sort of transaction, either, by the nature of IB generators. The drawback is that even when you rollback, generator's value isn't getting back, it's incrementing each time instead. Max(pkey_name) would help if you used locking transactions, that were bad(tm). Best regards, Michael mailto:mi...@ch... |
|
From: Michael S. <mi...@ch...> - 2000-10-04 19:29:22
|
Hello Flemming, Wednesday, October 04, 2000, 3:41:45 PM, you wrote: FF> Because of the client meory leaks talked about you should probably FF> keep an eye on the size of those apache processes and twiddle the FF> max requests pr child parameter in apache, but you're probably already FF> doing this, right? I'm using MaxRequestPerChild config parameter or Apache::SizeLimit module. The first is faster a bit, but the second gives more flexibility, maybe. Best regards, Michael mailto:mi...@ch... |
|
From: Mark D. A. <md...@di...> - 2000-10-04 17:08:47
|
> How do you know what id the generator made up for you? i get it in a preliminary select, then supply it in the insert. i know, you are groaning, 2 sql operations, but it does work. btw, regarding the "Morning Bug" -- have you seen it with interbase? i certainly have, but only with SS, not classic, and it might be useful to have more sample data. It Is Not Supposed To Happen (TM). -mda |
|
From: Flemming F. <di...@sw...> - 2000-10-04 16:41:27
|
"Mark D. Anderson" wrote: > > I'd like to know why you feel that this is unreliable, have I missed > > something? > > probably not. > > but by my understanding, if you generate a primary key value for an > insert by taking max+1 of the "current" ones, No I don't, the key is generated by a trigger that gets it from a generator. I use select max(id) ... to get the value that the trigger found for me when I did the insert. > another benefit of this is that i then know what the > pkey value is of the new row, as an insert doesn't > return anything but a success code. How do you know what id the generator made up for you? |
2 messages has been excluded from this view by a project administrator.
