[libdbi-users] [ANN] Ingres(R) 2006 driver committed to libdbi-drivers

2006-06-01 Thread Toby Thain
Hi,

Driver is almost complete. Please note the following:
- Autocommit mode is enabled by default  works. Multi-statement  
transactions don't work well yet.
- Long/blob and Unicode 'national character set' column types not  
supported yet, but all other Ingres types are supported including  
DECIMAL and MONEY.

More information in driver documentation files.

Tested with Ingres(R) 2006 Community Edition 9.0.4 for Linux/x86, on  
Gentoo. Ingres is a mature RDBMS now available under both commercial  
support and GPL terms. Particular strengths are in query  
optimisation, partitioning, security/auditing and clustering. More  
information on Ingres can be found here: http://ingres.com/products/ 
Prod_Ingres_2006.html

--Toby


___
libdbi-users mailing list
libdbi-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-users


Re: [libdbi-users] [libdbi-devel] driver issues and timezones

2007-02-15 Thread Toby Thain

On 12-Feb-07, at 3:38 AM, Markus Hoenicka wrote:

 Toby Thain [EMAIL PROTECTED] was heard to say:

 I wish Sourceforge would deprecate tarballs entirely and just use Svn
 tags. It seems (from another project I'm on, at least) that the
 tarball is always woefully out of date.

 My advice - go ahead and make a new release.


 Well, we'd have to move to subversion first in order to make use of  
 SVN tags.

 I'm afraid that releasing SVN tags instead of tarballs will deter  
 end-users
 who just need to satisfy some application dependency. A tarball is  
 something
 familiar to non-technical Unix/Linux users, whereas subversion is  
 not. Package
 maintainers are also used to build from tarball releases. Besides,  
 if I find
 the time to bless a subversion revision with a stable tag, most of  
 the work is
 done anyway. I can just as well build the tarball and upload it.  
 This takes
 just another cup of coffee's amount of time.

Mostly agreed. The other project's problem might be that the process  
of preparing the tarball is not documented and is done by one guy;  
also there is a trickle of commits, so somebody has to decide when a  
release is appropriate. The last tarball happened to be made at a  
very bad time (and was not updated yet), so this decision process  
failed us. Infrequent tarballs mean that, as I said, they're  
ridiculously out of date with respect to trunk. (libdbi seems more in  
maintenance than new development or frantic bugfixing, so it's not  
really the same case as that project.)

I stopped using tarballs in my own projects some time ago, it was  
only a source of problems.

 While we're at it: how do other developers and users feel about  
 moving libdbi
 development to subversion? Is it worth the hassle?


Assuming I'm included in other: My vote is yes, I'd feel more  
comfortable with Svn.

In answer to Claudiu:

 Why don't you release SVN tags and make tarballs, also? It's a good  
 idea
 to have a tag in SVN... ie: if you want to make a quick diff from the
 previous release version to trunk?

  Tag *must* be done when a tarball is made, I don't see that as  
optional.

--Toby


 regards,
 Markus


 -- 
 Markus Hoenicka
 [EMAIL PROTECTED]
 (Spam-protected email: replace the quadrupeds with mhoenicka)
 http://www.mhoenicka.de



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
libdbi-users mailing list
libdbi-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-users


Re: [libdbi-users] escape a string, not quoted

2008-01-15 Thread Toby Thain

On 15-Jan-08, at 12:58 PM, João Henrique Freitas wrote:

 Hello,

 Has libdbi some function to escape a string? Like PQescapeStringConn
 (http://www.postgresql.org/docs/current/interactive/libpq-exec.html).

Have you checked the libdbi manual?

--Toby


 I use dbi_conn_quote_string_copy, but it escape and quote the string.


 Thanks.

 PS: if not exists I will create this function in libdbi and send  
 the patch.

 -- 
 ---
 João Henrique Freitas - joaohf_at_gmail.com
 Campinas-SP-Brasil
 BSD051283
 LPI 1
 http://joaohf.pbwiki.com
 http://www.livejournal.com/users/joaohf/
 -- 
 ---
 This SF.net email is sponsored by: Microsoft
 Defy all challenges. Microsoft(R) Visual Studio 2008.
 http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
 ___
 libdbi-users mailing list
 libdbi-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/libdbi-users


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
libdbi-users mailing list
libdbi-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-users


Re: [libdbi-users] newline in query causes all field types to appear as DBI_TYPE_STRING

2008-10-13 Thread Toby Thain

On 13-Oct-08, at 7:15 AM, Markus Hoenicka wrote:

 Hi,

 just to clarify: it is sqlite, not the sqlite driver which does not
 support newlines in SQL statements.

Wow, that's inconvenient. I imagine that must break very many ORM/SQL  
generating layers.

--Toby

 Some other SQL engines like MySQL
 do support newlines, so this appears to be a design decision (I don't
 know what the standard says).

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
libdbi-users mailing list
libdbi-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-users


Re: [libdbi-users] UNIX Timestamp - DATE to UTC conversion

2008-11-19 Thread Toby Thain

On 19-Nov-08, at 8:42 AM, Ken Ramsay wrote:


 Thanks guys,

 MySQL defines the field as a DATETIME , so the return type is time_t.

No; you are using an expression, not the column, so the result type  
is indeed BIGINT, as Markus surmised (his explanation was correct, as  
far as I can determine).

 As
 far as I could find out, there is no helper funtion to convert this  
 into
 secs from 1 Jan 1970 ,

You indeed get seconds from UNIX epoch, as documented*, if you access  
the returned result field using 'dbi_result_get_longlong_idx()'.

(Or if you want to retrieve by name, I suggest using an alias for  
maintainability/readability's sake.)

--Toby

* - http://dev.mysql.com/doc/refman/5.0/en/date-and-time- 
functions.html#function_unix-timestamp


 so I got around it by using the difftime() call
 and subtracting the returned value from 1/1/1970. difftime()  
 returns the
 difference in seconds.

 Not sure it is the most elegant way to do it but it works ...;-}

 Cheers



 -Original Message-
 From: Markus Hoenicka [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, November 18, 2008 5:38 PM
 To: Ken Ramsay
 Cc: libdbi-users@lists.sourceforge.net; [EMAIL PROTECTED]
 Subject: [libdbi-users] UNIX Timestamp - DATE to UTC conversion

 Ken Ramsay writes:
   time = dbi_result_get_uint(result,
 UNIX_TIMESTAMP(HIST_Timestamp));

 Without actually trying the code: one rough guess is that MySQL  
 does not
 return the timestamp as an uint value but as something longer. Did you
 try using dbi_result_get_field_type() and
 dbi_result_get_field_attrib() to find out which type is returned?

 regards,
 Markus

 --
 Markus Hoenicka
 [EMAIL PROTECTED]
 (Spam-protected email: replace the quadrupeds with mhoenicka)
 http://www.mhoenicka.de


 This email was sent to you by Thomson Reuters, the global news and  
 information company.
 Any views expressed in this message are those of the individual  
 sender, except where the sender specifically states them to be the  
 views of Thomson Reuters.



 -- 
 ---
 This SF.Net email is sponsored by the Moblin Your Move Developer's  
 challenge
 Build the coolest Linux based applications with Moblin SDK  win  
 great prizes
 Grand prize is a trip for two to an Open Source event anywhere in  
 the world
 http://moblin-contest.org/redirect.php?banner_id=100url=/
 ___
 libdbi-users mailing list
 libdbi-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/libdbi-users


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK  win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
___
libdbi-users mailing list
libdbi-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-users


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

2010-01-18 Thread Toby Thain

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

 Toby Thain t...@telegraphics.com.au 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
 libdbi-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/libdbi-users


--
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
libdbi-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-users


Re: [libdbi-users] New API?

2010-01-22 Thread Toby Thain

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
 libdbi-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/libdbi-users


--
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
libdbi-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-users


Re: [libdbi-users] libdbi transaction support

2013-01-25 Thread Toby Thain
On 25/01/13 7:40 PM, markus.hoeni...@mhoenicka.de wrote:
 Markus Hoenicka writes:
 Another possible reason for problems is the table type. If someone
 uses MyISAM tables, the result I got would be expected. However, MySQL
 uses InnoDB tables as default these days, and I double-checked that
 they were used in my tests.

 Turns out that InnoDB is the default engine only in versions 5.5.5 and
 later. On my box, MyISAM tables were created by default. The test

Yes, you just found out the hard way that it's wise to include ENGINE 
specifications in MySQL CREATE TABLE's.

They took far too long to change the default engine to InnoDB.

--Toby

 correctly found out that the latter don't support transactions :-(

 I've changed the CREATE TABLE statement on my box to ask for InnoDB
 tables instead. This eliminates the failure of the rollback test.

 I'll try and finish the test suite asap. The transaction tests require
 some polish as they should run only if the driver supports
 transactions.

 regards,
 Markus



--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
libdbi-users mailing list
libdbi-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-users


Re: [libdbi-users] libdbi transaction support

2013-01-26 Thread Toby Thain
On 26/01/13 8:30 PM, markus.hoeni...@mhoenicka.de wrote:
 Toby Thain writes:
 Yes, you just found out the hard way that it's wise to include ENGINE
 specifications in MySQL CREATE TABLE's.
   

 True indeed.

Actually I think the news is even worse: I seem to recall that MySQL can 
even *ignore* ENGINE specifications if the engine isn't installed. 
Leaving you, again, with MyISAM-the-inadequate.

More silent fail. I think I've wasted some time on that one in the past.

--Toby



 regards,
 Markus



--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
___
libdbi-users mailing list
libdbi-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-users