Re: DBI on a pocketPC - preliminary success
On Wednesday, Dec 18, 2002, at 01:26 Europe/London, Jeff Zucker wrote: Just a preliminary report - thanks to Rainier Keuchel's port of perl to winCE, I now have DBI (PurePerl) and DBD::AnyData doing database read access on my Toshiba e740 (a palm-like handheld running pocketPC on an xScale processor). The port also works on most other pocketPC and winCE device (e.g. Ipaq, Jornada, Casio, Dell Axim, etc.). Total storage requirement for perl, perlIDE, and all the required modules is about 3mb so it should run on a fairly minimal device, even one with no storage card and a low amount of ROM. I'll be doing more testing with other DBDs and eventually with Shell and Proxy. If anyone else is working on this, let me know. It'd be cool to see if DBD::SQLite worked there - then you'd have a fully transaction aware database on a handheld! Matt.
Re: Metadata methods in DBI - NUM_PREC_RADIX once or twice?
Dear Tim, Errrmmm... Is NUM_PREC_RADIX at 15 or 18 or both? I think it should be at 18 only. I note that the numbers in the type_info_all array/hash are off-by-one compared with the SQLGetTypeInfo() method in ODBC, and SQL_DATA_TYPE appears at 16 in the current version of the man page at MS web site, so it should be at 15 in DBI; then SQL_DATETIME_SUB, NUM_PREC_RADIX and INTERVAL_PRECISION (at 19 in MS/ODBC, 18 in DBI)? Is that correct? If so, then we need to note that the DBI 1.32 spec which places NUM_PREC_RADIX at 15 leaves us with a compatibility problem? grin Maybe we should have the zeroth column as the DBI version number, and then have the other column numbers matching the ODBC spec? /grin That seems more than a trifle wasteful, not to mention backwards incompatible, so it is not a very serious suggestion. -- Jonathan Leffler ([EMAIL PROTECTED]) STSM, Informix Database Engineering, IBM Data Management Solutions 4100 Bohannon Drive, Menlo Park, CA 94025 Tel: +1 650-926-6921 Tie-Line: 630-6921 I don't suffer from insanity; I enjoy every minute of it! |-+ | | Tim Bunce| | | Tim.Bunce@pobox.| | | com | | || | | 12/16/2002 04:38 | | | AM | | || |-+ -| | | | To: Jonathan Leffler [EMAIL PROTECTED] | | cc: Tim Bunce [EMAIL PROTECTED], DBI Developers Mailing List [EMAIL PROTECTED], Jonathan Leffler/Menlo Park/IBM@IBMUS | | Subject: Re: Metadata methods in DBI | | | | | -| On Mon, Dec 16, 2002 at 03:21:12AM -0800, Jonathan Leffler wrote: Yet another question -- given the specifications of type_info_all and type_info, how does type_info get hold of the SQL_DATA_TYPE, SQL_DATETIME_SUB and INTERVAL_PRECISION fields, given that they are not listed in the type_info_all structure? Ah, [...rummages in ODBC 3.5 reference book...] Okay, I've just added these extra items to the info to be returned by type_info_all: SQL_DATA_TYPE = 16, DATETIME_SUB = 17, NUM_PREC_RADIX= 18, INTERVAL_PRECISION= 19, I'd just left them out when I added the extra field descriptions into the type_info docs. Note that DATETIME_SUB is misspelled with an SQL_ prefix in the docs. That's wrong. Fixed now. Driver authors please note! Also, the spiel for SQL_DATA_TYPE says: quoteThis column is the same as the DATA_TYPE column, except for interval or datetime types. For interval and datetime data types, the SQL_DATA_TYPE field will return SQL_INTERVAL or SQL_DATETIME, and the SQL_DATETIME_SUB field will return the subcode for the specific interval or datetime data type. If this field is NULL, then the driver does not support or report on interval or date types./quote Questions arising: 1. That last 'date' should be 'datetime' to be consistent. Yeap. Fixed. Thanks. 2. What does the DATA_TYPE field contain when this field contains SQL_DATETIME or SQL_INTERVAL? Not that value - but which value? The consise type integer, ie 112 for SQL_INTERVAL_HOUR_TO_SECOND. So when SQL_DATA_TYPE = SQL_DATETIME or SQL_INTERVAL then DATA_TYPE == DATETIME_SUB. (Yes, DATETIME_SUB does seem redundant but that's what the ODBC spec calls for.) In the context of type_info_all, you say 'driver-specific columns of information ... start at column index 50 to leave room for expansion'. How do you write an initializer for the gap between the 14 (17?) defined attributes and the index where the driver-specific attributes can start? Or is that a subtle hint not to define driver-specific attributes? I'm looking at the code with lines like: [ 'INTEGER', SQL_INTEGER, undef, , , undef, ... ], With the first 14 columns defined, there has to be 36 empty columns left unefined, or zeroed, or something; is there a neat notation to do that? 36*undef or something useful?
Re: DBI v1.32 - Code generator for $dbh-type_info_all (and Q about $dbh-type_info)
Jonathan Leffler wrote: [...] Can anyone explain the bit in the type_info method description (cribbed from the ODBC documentation, I'm sure) about 'ordered by DATA_TYPE first and then by how closely each type maps to the corresponding ODBC SQL data type, closest first'. SQL/CLI defines the result set as: SELECT * FROM TYPE_INFO ORDER BY DATA_TYPE Thus, it is undefined how equal DATA_TYPEs are ordered. The ODBC spec tries to be more precise - but remains vague. Steffen
RE: DBI v1.32 - Code generator for $dbh-type_info_all (and Q about $dbh-type_info)
[heavily snipped] It takes the output from DBD::ODBC's type_info_all method and maps it writes a new copy of the hash. I actually wrote it to handle the extra attributes you documented, and was pleasantly surprised to find DBD::ODBC 1.01 already providing the extra attributes (possibly simply because the ODBC driver I was using provided them too, but maybe there was more to it than that). That's going to depend upon your driver manager (DM), your driver and how you represent yourself to the DM (I.e. ODBC 2.x application or ODBC 3.x). I believe the DM should map the correct result set depending upon how the application represents itself to the DM. As of DBD::ODBC 0.43_1, DBD::ODBC tries to be an ODBC 3.x app instead of a 2.x app. That was one of the *major* changes in DBD::ODBC and brought to light a LOT of quirks. Lots of things are up in the air, though, when you link directly to the driver. You are *very* dependant upon what the driver tells you. I really can't take credit here, becase I'm just calling the appropriate ODBC API, not creating it myself. So, give the Informix CLI folks their due. Regards, Jeff
Re: DBI v1.32 - Code generator for $dbh-type_info_all (and Q about $dbh-type_info)
On 18-Dec-2002 Steffen Goeldner wrote: Jonathan Leffler wrote: [...] Can anyone explain the bit in the type_info method description (cribbed from the ODBC documentation, I'm sure) about 'ordered by DATA_TYPE first and then by how closely each type maps to the corresponding ODBC SQL data type, closest first'. SQL/CLI defines the result set as: SELECT * FROM TYPE_INFO ORDER BY DATA_TYPE Thus, it is undefined how equal DATA_TYPEs are ordered. The ODBC spec tries to be more precise - but remains vague. Vague but in practise useful. Take the output from MS SQL Server: type_name,local_type_name, sqltype sql_variant, sql_variant, -150 uniqueidentifier, uniqueidentifier, -11 ntext, ntext, -10 nvarchar, nvarchar, -9 sysname, sysname, -9 nchar, nchar, -8 bit, bit, -7 tinyint, tinyint, -6 tinyint identity, tinyint identity, -6 bigint, bigint, -5 bigint identity, bigint identity, -5 image, image, -4 varbinary, varbinary, -3 binary, binary, -2 timestamp, timestamp, -2 text, text, -1 char, char, 1 numeric, numeric, 2 numeric() identity, numeric() identity, 2 decimal, decimal, 3 money, money, 3 smallmoney, smallmoney, 3 decimal() identity, decimal() identity, 3 int, int, 4 int identity, int identity, 4 smallint, smallint, 5 smallint identity, smallint identity, 5 float, float, 6 real, real, 7 datetime, datetime, 11 smalldatetime, smalldatetime, 11 varchar, varchar, 12 If you want a SQL_INTEGER (4) column you'll see int before int identity which makes sense. If you want a SQL_DECIMAL (3) you'll get decimal before money, smallmoney or decimal identity. If I remember correctly, the DBD::ODBC tests sort of make use of this when attempting to find column types to use in a test table. Martin -- Martin J. Evans Easysoft Ltd, UK Development
Re: DBI on a pocketPC - preliminary success
Hi Matt, It'd be cool to see if DBD::SQLite worked there - then you'd have a fully transaction aware database on a handheld! At the moment I don't have a compiler or SDK for the pocketPC so I'm just using other people's prebuilt binaries plus pure perl modules (don't even have some basics like getOpt/Long which is making it difficult to test out Shell.pm). But I'll be glad to test out SQLite if I ever get the tools. -- Jeff
Fwd: Unicode in DBD::Pg
DBI-Dev'ers,
Below please find a message I forward from dbi-users. Although I
haven't noticed a problem with Unicode and DBD::Pg, but this message
did lead me to wonder if setting the UTF8 flag is something that we may
actually be needing to do in the drivers, and if so, is this the right
way to do it?
Thanks,
David
Begin forwarded message:
From: Dominic Mitchell [EMAIL PROTECTED]
Date: Wed Dec 18, 2002 10:09:33 AM US/Pacific
To: David Wheeler [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Unicode in DBD::Pg
David Wheeler wrote:
On Wednesday, December 18, 2002, at 01:27 AM, Dominic Mitchell wrote:
% psql -l
List of databases
Name| Owner | Encoding
---+--+---
dom | dom | UNICODE
template0 | postgres | SQL_ASCII
template1 | postgres | SQL_ASCII
(3 rows)
I'm using the -PGDG rpm, and looking at the spec file, it seems to
indicate that --enable-multibyte is not specified, but it should be
the default anyway. Is there a way that I can verify this from the
installed software?
I think the above does. I don't think you could have the encoding set
to UNICODE if it hadn't been compiled with --enable-multibyte.
Bother, that would have been easy. :-)
Attached is a patch to the driver which makes it work as expected for
me. I don't think it's the right patch, however... It should
probably only set the UTF8 flag when there is a high bit set in the
data. Attached is another patch which attempts to do that, although my
C skills are pretty rusty these days, so it could probably be written
a lot better!
Thanks,
-Dom
--
| Semantico: creators of major online resources |
| URL: http://www.semantico.com/ |
| Tel: +44 (1273) 72 |
| Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |
Index: dbdimp.c
===
RCS file: /usr/local/cvsroot/dbdpg/dbdpg/dbdimp.c,v
retrieving revision 1.8
diff -u -r1.8 dbdimp.c
--- dbdimp.c 27 Nov 2002 02:02:39 - 1.8
+++ dbdimp.c 18 Dec 2002 18:03:36 -
@@ -1391,6 +1391,7 @@
val[val_len] = '\0';
}
sv_setpvn(sv, val, val_len);
+ SvUTF8_on(sv);
}
}
Index: dbdimp.c
===
RCS file: /usr/local/cvsroot/dbdpg/dbdpg/dbdimp.c,v
retrieving revision 1.8
diff -u -r1.8 dbdimp.c
--- dbdimp.c 27 Nov 2002 02:02:39 - 1.8
+++ dbdimp.c 18 Dec 2002 18:07:37 -
@@ -1391,6 +1391,12 @@
val[val_len] = '\0';
}
sv_setpvn(sv, val, val_len);
+ {
+ char *s;
+ while( *s++ ) {
+ if (*s 0x80) SvUTF8_on(sv);
+ }
+ }
}
}
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
