On 29/06/2013 11:09, demerphq wrote:
On 28 June 2013 04:07, Paul DuBois p...@snake.net wrote:
On Jun 27, 2013, at 8:56 PM, Lyle wrote:
On 28/06/2013 02:34, Paul DuBois wrote:
On Jun 27, 2013, at 8:16 PM, Lyle wrote:
On 27/06/2013 22:22, Tim Bunce wrote:
If you're a DBD::mysql user and care
MySQL *5* support.
I was talking to Peter about extra hacking sessions at our last Perl
meet. I'll make sure this is on the agenda.
Lyle
On 28/06/2013 02:34, Paul DuBois wrote:
On Jun 27, 2013, at 8:16 PM, Lyle wrote:
On 27/06/2013 22:22, Tim Bunce wrote:
If you're a DBD::mysql user and care about the future of the code, please help
out.
I felt the same when I came across this during my research. I didn't have a
great deal
trmjoa
with a possible new member soon: Vince Willems
You can watch the effort in https://github.com/perl5-dbi/DBI-Test
The notes made in Lancaser are in
https://github.com/perl5-dbi/DBI-Test/blob/master/sandbox/qa2013-notes.txt
...
All sounds like a good effort :)
Lyle
On 18/04/2013 20:09, Paul DuBois wrote:
On Apr 18, 2013, at 12:07 PM, Patrick Galbraith wrote:
Lyle,
To be certain, they don't wish to kill DBD::mysql. They are really trying to
define what Oracle supports and what they do not. The were very helpful in painstakingly
migrating the bugs from
Hmm... Got a reply to my bug report and it's a bit worrying:
http://bugs.mysql.com/bug.php?id=68266
Seems like MySQL don't want to directly support DBD::mysql any more.
Whether you like mysql or not, that's a heavily used DBD.
Lyle
On 05/02/2013 09:09, Martin J. Evans wrote:
On 05/02/13 00:46, Lyle wrote:
Hi All, I just submitted bug 83132. It's nothing major, but after
upgrading to a newer DBI my comparison tool reported SQL_CHAR and
SQL_NUMERIC as DBIstcf_DISCARD_STRING and DBIstcf_STRICT. I could be
wrong, but it seems
for your feedback, much appreciated!
Lyle
On 05/02/2013 14:53, H.Merijn Brand wrote:
On Tue, 05 Feb 2013 14:33:38 +, Martin J. Evans
martin.ev...@easysoft.com wrote:
On 05/02/13 14:16, Lyle wrote:
Drivers are also free to return extra driver-specific columns of
information - though it's recommended that they start at column index
},
I just noticed that they don't mention this new column on their site:
http://msdn.microsoft.com/en-us/library/ms715410%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/ms714632%28v=vs.85%29.aspx
Lyle
.
Lyle
mailing list as you suggested.
Lyle
On 07/01/2013 13:08, Lyle wrote:
On 07/01/2013 10:43, H.Merijn Brand wrote:
On Sun, 30 Dec 2012 02:53:33 +, Lyle webmas...@cosmicperl.com
wrote:
Hi All,
Whilst working on another project it made sense to write a tool for
comparing the various RDBMSs...
Very useful indeed, but I'm
On 05/01/2013 20:49, Darren Duncan wrote:
On 2013.01.05 5:39 AM, Lyle wrote:
I'm not overly familiar with Perl's internal handling of number. I
guess if you
have DECIMAL from a character string Perl will switch it out to an
approximate
the moment you do a calculation on it. Furthermore
types, be that integer or character.
Lyle
.
PostgreSQL do recommend using VARCHAR instead of CHAR. Due to the way
they are implemented, VARCHAR is usually more efficient.
Lyle
not sure whether there is good reasoning behind them, or whether the DBD
developers have been doing a best guess and we might possibly want to
consider making things more consistent?
Lyle
-- Darren Duncan
Lyle wrote:
Hi All,
Whilst working on another project it made sense to write a tool
I could create in a new left column that
wouldn't match the current left column. I'm open to suggestions if you
want to send me some ideas.
Lyle
I'm sorry. Me and Darren are having this conversation on two separate
lists (this one and TTM) that we are both part of, but have a
substantially different subscriber base. This response was supposed to
have gone to TTM.
Lyle
On 30/12/2012 16:45, Lyle wrote:
On 30/12/2012 04:19, Darren
by the DBD driver, or
whether this is already predetermined by the RDBMS...
Let me know if this isn't interesting to you all and I'll keep it off list.
Lyle
!
Working on it. If no one comes back with a better resource, should I add
a description of how to find the ODBC codes from the header files?
Lyle
to a google link.
If I can help with this, let me know, I can submit patches.
Lyle
5.10...
So at this time the impact of such change could be significant.
Lyle
On 22/07/2010 07:40, Martin J. Evans wrote:
Lyle wrote:
Hi,
So far I've seen:
NOTICE: CREATE TABLE / UNIQUE will create implicit index FOO_BAR for
table FOO
Lyle
Did you look at PrintWarn.
Opps sorry, serves me right for sending email right before I go to sleep
Hi,
So far I've seen:
NOTICE: CREATE TABLE / UNIQUE will create implicit index FOO_BAR for
table FOO
Lyle
Hi,
Is it ok to send you a patch for this Tim?
Lyle
On 18/07/2010 03:37, Lyle wrote:
The new naming of sections, such as
DBI.pm#RaiseError_(boolean,_inherited) has broken a lot of in page
links, such as L/RaiseError.
Lyle
The new naming of sections, such as
DBI.pm#RaiseError_(boolean,_inherited) has broken a lot of in page
links, such as L/RaiseError.
Lyle
27 matches
Mail list logo
