libdbi-users — General libdbi discussion and support

Re: [libdbi-users] Timeout / Reconnect

[Vikram A. <noe...@gm...>]

On 07/01/2010 03:12 AM, Markus Hoenicka wrote:
> Vikram Ambrose <noe...@gm...> was heard to say:
>
>> Is there a way of having the mysql driver, reconnect and then complete
>> the query without erroring out, in the case of driver/server timeout?
>> This way I do not lose my query to a timeout or need to have some sort
>> of global command buffer that the callback would use to re-execute the
>> failed query.
>
> Hi,
>
> does the MySQL API provide enough information to tell from a failure 
> of mysql_query that the connection has stalled? I've found a log entry 
> in cvs which added a timeout option to the driver, so with that in 
> place and a useful error message from libmysqlclient I'd say it's 
> doable. We'd just have to loop over a limited number of retries, 
> trying to reconnect each time before resending the query.
>

There is indeed enough information to find this scenario. Here is a very 
simple callback I use at the moment:

void DB_error_callback(dbi_conn conn, void *udata){
     int rv;
     const char *errormsg = NULL;

     rv = dbi_conn_error(DB_conn,&errormsg);
     if(strstr(errormsg,"gone away")){
         rv = dbi_conn_connect(DB_conn);
         if(rv){
             printf("ERROR: DB_error_callback: Tried to reconnect - 
failed\n");
         }else {
             printf("ERROR: DB_error_callback: Reconnected\n");
         }
     }
}

Re: [libdbi-users] Timeout / Reconnect

[Markus H. <mar...@mh...>]

Vikram Ambrose <noe...@gm...> was heard to say:

> Is there a way of having the mysql driver, reconnect and then complete
> the query without erroring out, in the case of driver/server timeout?
> This way I do not lose my query to a timeout or need to have some sort
> of global command buffer that the callback would use to re-execute the
> failed query.

Hi,

does the MySQL API provide enough information to tell from a failure  
of mysql_query that the connection has stalled? I've found a log entry  
in cvs which added a timeout option to the driver, so with that in  
place and a useful error message from libmysqlclient I'd say it's  
doable. We'd just have to loop over a limited number of retries,  
trying to reconnect each time before resending the query.

regards,
Markus


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

[libdbi-users] Timeout / Reconnect

[Vikram A. <noe...@gm...>]

I make use of the mysql driver and I find that when I come back to my PC 
the next day, the first query I issue always results in an error. I need 
to reconnect to the server for it to work again.

I've setup a callback to do the reconnect, but the original query is lost.

Is there a way of having the mysql driver, reconnect and then complete 
the query without erroring out, in the case of driver/server timeout? 
This way I do not lose my query to a timeout or need to have some sort 
of global command buffer that the callback would use to re-execute the 
failed query.


Vikram.

[libdbi-users] New release

[Markus H. <mar...@mh...>]

Phil Longstaff writes:
 > any idea on when the next release of libdbi will be?  It's been a long
 > time since the last one and there are some good changes in svn.

Hi,

I wouldn't place any bets. I've been discussing things with João
lately, he has put an enormous amount of effort into updating our test
harness which is way better than the old one. We ran into problems
with firebird which both of us were unable to solve. Our latest guess
is that the test code triggers a documented firebird bug which we
can't work around. If we drop firebird support for now, we could
release a new version after doing some minor cleanup. Unfortunately
I'm haunted by a couple of deadlines in the next couple of weeks, so
it is very uncertain whether I'll be able to finalize a release.

Needless to say, test reports using the current cvs version are always
welcome.


regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

[libdbi-users] New release

[Phil L. <plo...@ro...>]

Hi,

any idea on when the next release of libdbi will be?  It's been a long
time since the last one and there are some good changes in svn.

Phil

Re: [libdbi-users] New API?

[Markus H. <mar...@mh...>]

Toby Thain <to...@te...> was heard to say:

> I think the deprecation is progressive because all in all it is
> better if users always specify their instance explicitly. Hidden
> global data has proven to be a liability in many such instances
> (strtok(), errno, ...)

This is certainly the rationale behind the decision to deprecate the  
old versions. Also, most applications will only have to define an  
additional structure and pass an additional argument in three function  
calls. Sanity doesn't always come that cheap.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] New API?

[Toby T. <to...@te...>]

On 22-Jan-10, at 9:19 PM, Vikram Noel Ambrose wrote:

> Markus Hoenicka wrote:
>> The older versions (dbi_initialize, dbi_conn_new and dbi_shutdown)  
>> are
>> now implemented on top of these functions, using a single static  
>> instance
>> handle.
>>
>
> Then why should those functions be deprecated? I'm sure the  
> majority of
> users do not have such peculiar requirements. I vote for them staying.

AFAIK the old functions are also not safe for threaded applications.

I think the deprecation is progressive because all in all it is  
better if users always specify their instance explicitly. Hidden  
global data has proven to be a liability in many such instances  
(strtok(), errno, ...)

--Toby

>
>
> Vikram.
>
> ---------------------------------------------------------------------- 
> --------
> Throughout its 18-year history, RSA Conference consistently  
> attracts the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> libdbi-users mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-users

Re: [libdbi-users] New API?

[Vikram N. A. <noe...@gm...>]

Markus Hoenicka wrote:
> The older versions (dbi_initialize, dbi_conn_new and dbi_shutdown) are
> now implemented on top of these functions, using a single static instance
> handle.
>   

Then why should those functions be deprecated? I'm sure the majority of 
users do not have such peculiar requirements. I vote for them staying.


Vikram.

[libdbi-users] New API?

[Markus H. <mar...@mh...>]

Vikram Noel Ambrose writes:
 > I just built libdbi and libdbi-drivers from svn. When recompiling my 
 > application, I got a warning saying, dbi_initialize, dbi_conn_new and 
 > dbi_shutdown has been deprecated.
 > 
 > I think the docs online are out of data:
 > http://libdbi.sourceforge.net/docs/programmers-guide/reference-core.html
 > 
 > What are those functions being replaced with?

The docs reflect the situation as of the latest official release. This
should probably be spelled out somewhere to make things clear. If you
fiddle with the current svn version, please build the programmers
guide from the sources.

The current svn version implements a new feature called "instances"
which required us to change the API slightly. In a nutshell, a libdbi
instance allows you to initialize libdbi, load and unload drivers, and
shut down the library independently from other parts of your program
which also use libdbi. The problem came up with some piece of software
which was designed to load modules at runtime. Some of these modules
used libdbi. In order to unload such a module properly, you'd have to
shut down the library. But that would have made libdbi unavailable to
the remaining modules.

Therefore the new interface uses instance handles to manage the
library. A single process can open as many instances as it needs, and
initialize and shut them down individually. The new initializer
requires a pointer to a dbi_inst structure:

int dbi_initialize_r(const char *driverdir, dbi_inst *pInst);

You'll need this handle later to create connections and to shut down
the instance:

dbi_conn dbi_conn_new_r(const char *name, dbi_inst Inst);
void dbi_shutdown_r(dbi_inst Inst);

The older versions (dbi_initialize, dbi_conn_new and dbi_shutdown) are
now implemented on top of these functions, using a single static instance
handle.

HTH
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

[libdbi-users] New API?

[Vikram N. A. <noe...@gm...>]

I just built libdbi and libdbi-drivers from svn. When recompiling my 
application, I got a warning saying, dbi_initialize, dbi_conn_new and 
dbi_shutdown has been deprecated.

I think the docs online are out of data:
http://libdbi.sourceforge.net/docs/programmers-guide/reference-core.html

What are those functions being replaced with?


Vikram.

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Markus H. <mar...@mh...>]

Vikram Noel Ambrose <noe...@gm...> was heard to say:

> By the way, the url for the source code repository is dead on the website.

Thanks for the heads up. I may have missed a SourceForge announcement  
about restructuring their CVS servers.

regards,
Markus


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Vikram N. A. <noe...@gm...>]

Markus Hoenicka wrote:
> Vikram Noel Ambrose writes:
>  > Yes of course. VARCHAR should be treated as NULL terminated character 
>  > strings and not binary. As long as libdbi is consistent as to what it 
>  > thinks a "VARCHAR(256) COLLATE 'binary'" refers to, then I'll be happy.
>  > 
>
> I've checked in a fixed version of dbd_mysql.c. I've also pasted in
> the patch below. It should apply cleanly to previous versions as well,
> as that part of the code hasn't been touched for a while. Vikram,
> could you please check whether this fixes your problem?
>   

Looks like its working Markus. Tested using mysql-5.1.37 on Ubuntu-9.10 
x86_64.

By the way, the url for the source code repository is dead on the website.


Vikram.

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Markus H. <mar...@mh...>]

Vikram Noel Ambrose writes:
 > Yes of course. VARCHAR should be treated as NULL terminated character 
 > strings and not binary. As long as libdbi is consistent as to what it 
 > thinks a "VARCHAR(256) COLLATE 'binary'" refers to, then I'll be happy.
 > 

I've checked in a fixed version of dbd_mysql.c. I've also pasted in
the patch below. It should apply cleanly to previous versions as well,
as that part of the code hasn't been touched for a while. Vikram,
could you please check whether this fixes your problem?

regards,
Markus

--- dbd_mysql.c	2009/10/13 21:56:18	1.101
+++ dbd_mysql.c	2010/01/19 23:35:08	1.102
@@ -21,7 +21,7 @@
  * Copyright (C) 2001-2002, Mark Tobenkin <ma...@br...>
  * http://libdbi.sourceforge.net
  * 
- * $Id: dbd_mysql.c,v 1.101 2009/10/13 21:56:18 mhoenicka Exp $
+ * $Id: dbd_mysql.c,v 1.102 2010/01/19 23:35:08 mhoenicka Exp $
  */
 
 #ifdef HAVE_CONFIG_H
@@ -675,8 +675,6 @@
 			_attribs |= DBI_DATETIME_DATE | DBI_DATETIME_TIME;
 			break;
 			
-		case FIELD_TYPE_VAR_STRING:
-		case FIELD_TYPE_STRING:
 		case FIELD_TYPE_TINY_BLOB:
 		case FIELD_TYPE_MEDIUM_BLOB:
 		case FIELD_TYPE_LONG_BLOB:
@@ -688,6 +686,8 @@
 				_type = DBI_TYPE_BINARY;
 				break;
 			}
+		case FIELD_TYPE_VAR_STRING:
+		case FIELD_TYPE_STRING:
 #ifdef FIELD_TYPE_NEWDECIMAL
 		case FIELD_TYPE_NEWDECIMAL: // Precision math DECIMAL or NUMERIC field (MySQL 5.0.3 and up)
 #endif


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Vikram N. A. <noe...@gm...>]

Toby Thain wrote:
> On 18-Jan-10, at 7:38 PM, Markus Hoenicka wrote:
>
>   
>> Markus Hoenicka writes:
>>     
>>> information. This check simply looks spurious to me:
>>>
>>> if(field->charsetnr == 63)
>>>
>>>       
>> It probably isn't as wrong as I thought initially. MySQL gurus, please
>> correct me if I'm wrong, but I take the following from the manual:
>>
>> The purpose of the field->charsetnr==63 is to tell TEXT and BLOB
>> fields apart (and their relatives of other sizes). Both are
>> represented by a FIELD_TYPE_BLOB (or MYSQL_TYPE_BLOB) type. The former
>> is a NULL-terminated string with a character set and a collation, the
>> latter is a binary object without character set or collation. There is
>> apparently no way to tell these apart other than by their
>> field->charsetnr value.
>>
>> Therefore I tend to think the proper fix is to rearrange the case
>> statements in the mysql driver (see the _translate_mysql_type
>> function). The VAR_STRING and STRING types should be moved below the
>> default: entry to never mark those as binary.
>>     
>
> I haven't looked at the code, but that sounds good.
>
>   
>> Vikram, do I understand correctly that you don't expect to be able to
>> store binary strings in a "VARCHAR(256) COLLATE 'binary'" column? If
>> we fix the driver as I suggested above, you'd get back only the part
>> of the string up to the first NULL.
>>     
>
> Seems like a quite reasonable expectation when fetching using _string  
> function.
>
>   

Yes of course. VARCHAR should be treated as NULL terminated character 
strings and not binary. As long as libdbi is consistent as to what it 
thinks a "VARCHAR(256) COLLATE 'binary'" refers to, then I'll be happy.

Vikram.

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Toby T. <to...@te...>]

On 18-Jan-10, at 7:38 PM, Markus Hoenicka wrote:

> Markus Hoenicka writes:
>> information. This check simply looks spurious to me:
>>
>> if(field->charsetnr == 63)
>>
>
> It probably isn't as wrong as I thought initially. MySQL gurus, please
> correct me if I'm wrong, but I take the following from the manual:
>
> The purpose of the field->charsetnr==63 is to tell TEXT and BLOB
> fields apart (and their relatives of other sizes). Both are
> represented by a FIELD_TYPE_BLOB (or MYSQL_TYPE_BLOB) type. The former
> is a NULL-terminated string with a character set and a collation, the
> latter is a binary object without character set or collation. There is
> apparently no way to tell these apart other than by their
> field->charsetnr value.
>
> Therefore I tend to think the proper fix is to rearrange the case
> statements in the mysql driver (see the _translate_mysql_type
> function). The VAR_STRING and STRING types should be moved below the
> default: entry to never mark those as binary.

I haven't looked at the code, but that sounds good.

>
> Vikram, do I understand correctly that you don't expect to be able to
> store binary strings in a "VARCHAR(256) COLLATE 'binary'" column? If
> we fix the driver as I suggested above, you'd get back only the part
> of the string up to the first NULL.

Seems like a quite reasonable expectation when fetching using _string  
function.


--Toby


>
> regards,
> Markus

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Markus H. <mar...@mh...>]

Markus Hoenicka writes:
 > information. This check simply looks spurious to me:
 > 
 > if(field->charsetnr == 63)
 > 

It probably isn't as wrong as I thought initially. MySQL gurus, please
correct me if I'm wrong, but I take the following from the manual:

The purpose of the field->charsetnr==63 is to tell TEXT and BLOB
fields apart (and their relatives of other sizes). Both are
represented by a FIELD_TYPE_BLOB (or MYSQL_TYPE_BLOB) type. The former
is a NULL-terminated string with a character set and a collation, the
latter is a binary object without character set or collation. There is
apparently no way to tell these apart other than by their
field->charsetnr value.

Therefore I tend to think the proper fix is to rearrange the case
statements in the mysql driver (see the _translate_mysql_type
function). The VAR_STRING and STRING types should be moved below the
default: entry to never mark those as binary.

Vikram, do I understand correctly that you don't expect to be able to
store binary strings in a "VARCHAR(256) COLLATE 'binary'" column? If
we fix the driver as I suggested above, you'd get back only the part
of the string up to the first NULL.

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Markus H. <mar...@mh...>]

Toby Thain <to...@te...> was heard to say:

> I have discussed this issue with Vikram on #mysql and IMHO it is
> wrong in concept for a collation change to affect column type: As it
> is not concerning the contents of the field but merely
> interpretation. Naturally he didn't expect to have to change his code.
>
> But then perhaps the driver writer held a different opinion.

I totally agree here, collation should not affect column type. I still  
suspect that MySQL reports the column type correctly, but that the  
driver uses incorrect or insufficient means to interpret this  
information. This check simply looks spurious to me:

if(field->charsetnr == 63)

This looks more to me like a crutch than like an author having a  
different opinion. Toby, isn't there a more foolproof check available  
in the MySQL C API?

regards,
Markus


-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Toby T. <to...@te...>]

On 18-Jan-10, at 3:47 AM, Markus Hoenicka wrote:

> Toby Thain <to...@te...> was heard to say:
>
>> This is probably driver dependent. IMHO the first check would be to
>> see if the unexpected reversion to binary type is occurring within
>> libdbi or in libmysqlclient (or mysqld).
>>
>
> I bet it is. The mysql driver uses some weird check (in
> _translate_mysql_type) to find out whether or not a field is binary.
> Unless I'm dense the code in question may actually cause other
> problems as well,

I have discussed this issue with Vikram on #mysql and IMHO it is  
wrong in concept for a collation change to affect column type: As it  
is not concerning the contents of the field but merely  
interpretation. Naturally he didn't expect to have to change his code.

But then perhaps the driver writer held a different opinion.

> so I'd like to ask everyone with some MySQL
> knowledge to have a look at it.

Sure.

--Toby

> Also, the existing check may be
> version dependent. Vikram, which MySQL version are you running?
>
> regards,
> Markus
>
> -- 
> Markus Hoenicka
> http://www.mhoenicka.de
> AQ score 38
>
>
>
> ---------------------------------------------------------------------- 
> --------
> Throughout its 18-year history, RSA Conference consistently  
> attracts the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> libdbi-users mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-users

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Markus H. <mar...@mh...>]

Toby Thain <to...@te...> was heard to say:

> This is probably driver dependent. IMHO the first check would be to
> see if the unexpected reversion to binary type is occurring within
> libdbi or in libmysqlclient (or mysqld).
>

I bet it is. The mysql driver uses some weird check (in  
_translate_mysql_type) to find out whether or not a field is binary.  
Unless I'm dense the code in question may actually cause other  
problems as well, so I'd like to ask everyone with some MySQL  
knowledge to have a look at it. Also, the existing check may be  
version dependent. Vikram, which MySQL version are you running?

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Toby T. <to...@te...>]

On 17-Jan-10, at 8:36 PM, Vikram Noel Ambrose wrote:

> Markus Hoenicka wrote:
>> Vikram Noel Ambrose writes:
>>> Either mysql is telling libdbi that the field is binary or libdbi is
>>> getting confused somewhere.
>>>
>>
>> Could you please insert a call to dbi_result_get_field_type_idx() to
>> see what mysql thinks this is?
>>
>
> It returns type 4. Which is DBI_TYPE_BINARY in my dbi.h
>
> I don't have another db to test with at the moment, but does this  
> return
> type 4 when using other drivers on a column declared varchar with  
> binary
> collation?

This is probably driver dependent. IMHO the first check would be to  
see if the unexpected reversion to binary type is occurring within  
libdbi or in libmysqlclient (or mysqld).

--Toby

>
> It should always be type 3 (DBI_TYPE_STRING).
>
> Vikram.
>
> ---------------------------------------------------------------------- 
> --------
> Throughout its 18-year history, RSA Conference consistently  
> attracts the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> libdbi-users mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdbi-users

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Vikram N. A. <noe...@gm...>]

Markus Hoenicka wrote:
> Vikram Noel Ambrose writes:
>  > Either mysql is telling libdbi that the field is binary or libdbi is 
>  > getting confused somewhere.
>  > 
>
> Could you please insert a call to dbi_result_get_field_type_idx() to
> see what mysql thinks this is?
>   

It returns type 4. Which is DBI_TYPE_BINARY in my dbi.h

I don't have another db to test with at the moment, but does this return 
type 4 when using other drivers on a column declared varchar with binary 
collation?

It should always be type 3 (DBI_TYPE_STRING).

Vikram.

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Markus H. <mar...@mh...>]

Vikram Noel Ambrose writes:
 > Either mysql is telling libdbi that the field is binary or libdbi is 
 > getting confused somewhere.
 > 

Could you please insert a call to dbi_result_get_field_type_idx() to
see what mysql thinks this is?

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

Re: [libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Vikram N. A. <noe...@gm...>]

Markus Hoenicka wrote:
> Vikram Noel Ambrose writes:
>  > When I invoke dbi_result_get_string_idx on a column declared 
>  > "VARCHAR(256) COLLATE 'binary'", libdbi complains that: "The requested 
>  > variable type does not match what libdbi thinks it should be".
>  > 
>  > I then tried using _get_binary_idx, but that seems to cause the next dbi 
>  > call to segfault (_get_short_idx). I wasn't sure if dbi was giving me 
>  > the '\0' character, so I called _get_field_length_idx and that just 
>  > returns 0. I don't have any idea whats going on now.
>  > 
>  > Has anyone else run into this?
>
> I've never tried things like this. Which driver do you use?
>
> regards,
> Markus
>
>   

This was on the mysql driver with mysql-5.1.37 on x86_64.

I managed to work around the problem with get_binary_idx but its rather 
inconvenient to treat null terminated character strings as binary.

Either mysql is telling libdbi that the field is binary or libdbi is 
getting confused somewhere.

VARCHAR should be "string" regardless of the collation used.

I wonder what would happen with another database.


Vikram.

[libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Markus H. <mar...@mh...>]

Vikram Noel Ambrose writes:
 > When I invoke dbi_result_get_string_idx on a column declared 
 > "VARCHAR(256) COLLATE 'binary'", libdbi complains that: "The requested 
 > variable type does not match what libdbi thinks it should be".
 > 
 > I then tried using _get_binary_idx, but that seems to cause the next dbi 
 > call to segfault (_get_short_idx). I wasn't sure if dbi was giving me 
 > the '\0' character, so I called _get_field_length_idx and that just 
 > returns 0. I don't have any idea whats going on now.
 > 
 > Has anyone else run into this?

I've never tried things like this. Which driver do you use?

regards,
Markus

-- 
Markus Hoenicka
http://www.mhoenicka.de
AQ score 38

[libdbi-users] dbi_result_get_string_idx fails on VARCHAR COLLATE 'binary'

[Vikram N. A. <noe...@gm...>]

When I invoke dbi_result_get_string_idx on a column declared 
"VARCHAR(256) COLLATE 'binary'", libdbi complains that: "The requested 
variable type does not match what libdbi thinks it should be".

I then tried using _get_binary_idx, but that seems to cause the next dbi 
call to segfault (_get_short_idx). I wasn't sure if dbi was giving me 
the '\0' character, so I called _get_field_length_idx and that just 
returns 0. I don't have any idea whats going on now.

Has anyone else run into this?


Vikram.