1.61 2020-01-30
[BUG FIXES]
Fix 12blob.t test by pali
Fix searching for ODBC libraries in system by pali (#15)
[ENHANCEMENTS]
use PERL_NO_GET_CONTEXT for more performance by markusbeth (#13)
[MISCELLANEOUS]
Fix travis builds for older Perls by pali
Thank you to all who
On 15/11/2018 23:54, Daniel Kasak wrote:
Hi Martin. Sorry for the very long delay. We had abandoned the ODBC
driver in favour of the native DBD::DB2, and I've been working on this
project outside my normal work hours anyway, so got bogged down in
other issues ...
I've uploaded th
mmented out all other lines mentioning LongReadLen or LongTruncOK.
This still gives:
Can't set DBI::db=HASH(0x55e58ba53e30)->{LongTruncOK}: unrecognised
attribute name or invalid value at
/usr/lib64/perl5/vendor_perl/5.26.2/x86_64-linux-thread-multi/DBI.pm line
730.
DBD::ODBC::st fetchrow_hashre
Hi Dan
Does it make any difference if you put LongReadLen and LongTruncOK next
to RaiseError in the attrs?
On 16/11/18 10:54, Daniel Kasak wrote:
Hi Martin. Sorry for the very long delay. We had abandoned the ODBC
driver in favour of the native DBD::DB2, and I've been working on
Hi Martin. Sorry for the very long delay. We had abandoned the ODBC driver
in favour of the native DBD::DB2, and I've been working on this project
outside my normal work hours anyway, so got bogged down in other issues ...
I've uploaded the trace to: https://tesla.duckdns.org/downloads
On 05/04/18 12:24, Daniel Kasak wrote:
Hi all.
I'm writing a database utility that has to access IBM's "DashDB" and other
DB2-variants. I have their latest ODBC driver, and I have simple queries working. However
queries against their system catalog are not working -
Hi all.
I'm writing a database utility that has to access IBM's "DashDB" and other
DB2-variants. I have their latest ODBC driver, and I have simple queries
working. However queries against their system catalog are not working -
queries appear to be returning *empty* re
I have uploaded DBD::ODBC 1.56 to the CPAN (1.54 was skipped due to an indexing
problem).
Here are the changes since the 1.52:
1.53_2 2016-02-03
[MISCELLANEOUS]
Add new FAQs
1.53_1 2015-10-16
[BUG FIXES]
Strictly speaking this is a bug fix to DBI and not DBD::ODBC but DBI
now
Martin has informed me that Microsoft doesn't support SQLDescribeParam and
in the absence of an explicit bind_param, miscasts the data as VARCHAR.
$sth->bind_param(1, undef, SQL_LONGVARBINARY);
Solved the problem.
--- Begin Message ---
On 28/01/16 15:08, Jerrad Pierce wrote:
Hello Martin,
$DBI::VERSION = 1.634
$DBD::ODBC::VERSION = 1.52
It would also be useful to know the column type in your access DB.
I'm updating a LONGBINARY column in a Jet 4 (MDB) database.
Thanks
Thank you
I forgo
On 27/01/16 22:10, Jerrad Pierce wrote:
Hello all, I'm updating a LONGBINARY column in a Jet 4 (MDB) database on
Windows 7 with
DBD::ODBC and have encountered an odd issue. Rather than the common problem of
Unicode
data being treated as bytes, I have bytes that seem to be being treated as
Hello all, I'm updating a LONGBINARY column in a Jet 4 (MDB) database on
Windows 7 with
DBD::ODBC and have encountered an odd issue. Rather than the common
problem of Unicode
data being treated as bytes, I have bytes that seem to be being treated
as UCS-2LE.
Data that should look like th
I have the problem whether I use the default DBD::ODBC from Strawberry Perl,
or one built specifically with Unicode disabled.
DBI::db=HASH(0x25f2608) trace level set to 0x6000100/2 (DBI @
0x0/0) in DBI1.634-ithread (pid 1844)
-> prepare for DBD::ODBC::db (DBI::db=HASH(0x25f2
I've just uploaded DBD::ODBC 1.53_1 to the CPAN.
The most significant change is to support DBI's new 64 bit row counts.
DBD::ODBC did (and still does) support 64 bit row counts via its own API but
this now means if you have an up to date DBI, you can use the normal return
from t
Hi,
I think this issue can now be closed. Frediano Ziglio was able to add some
changes to the FreeTDS driver to fix the issues.
Here's the comments from applicable the Git changes (I think):
Allow to close cursors and prepared statement when connection is idle
Using ODBC is possible
database
--
does some updates in SQLServer
The issue is that if I dont disconnect before running bcp, the op just
hangs (with no output).
If I disconnect before bcp and then reconnect everything is fine. Is
this a known issue
Platform Windows 7
SQLServer 2012
DBD::ODBC=1.609
updates in SQLServer
The issue is that if I dont disconnect before running bcp, the op just
hangs (with no output).
If I disconnect before bcp and then reconnect everything is fine. Is
this a known issue
Platform Windows 7
SQLServer 2012
DBD::ODBC=1.609
s?
Hi Mike,
What makes you point the finger at the statement handle not being freed?
Can you make this happen in a small standalone script and provide schema?
What ODBC driver are you using and what versions of DBI, DBD::ODBC and ODBC
driver manager?
Martin
I have the following script (extremley simplified)
foreach my $key (sort {$a<=>$b} keys %run){
my $inp;
$inp=$dbh->selectall_arrayref("select id, [description] from
Kaonix_import_base where idint between ? and ? ",undef,$run{$key}->[0],
$run{$key}->[1]) ;
addrec($inp); -- sub to run very heavy r
I have just uploaded DBD::ODBC 1.52 to the CPAN. Thanks to everyone who
reported issues and in particular to Greg for his Pull Request from the PR
challenge and to Neil for running it. If you are not part of the CPAN pull
request challenge I believe you can still join - see http://cpan-prc.org
I have to say at this point I'm pointing a finger at your driver as
> whatever, if it returns SQL_ERROR from SQLFreeHandle it should tell us
> the error when we call SQLError. However, your ODBC log is strange as
> it does not show any SQLFreeHandle call failing (and it does not look
&g
On 01/04/15 05:36, Joel Plotkin wrote:
Hi Martin,
I've attached a odbc device driver log (sql.log) and the dbi trace log at level
15 (x.log).
Hope this helps,
Joel
Joel,
Thanks for the logs but I'm not sure you are going to be too pleased with my
analysis.
There are a few poin
ine 74 via at test8.pl line 53
-> DESTROY for DBD::ODBC::st (DBI::st=HASH(0xac3818)~INNER) thr#974010
SQLFreeHandle(stmt)=-1
!!dbd_error2(err_rc=-1, what=st_destroy/SQLFreeHandle(stmt),
handles=(c2abd0,c2b1c0,c802c0)
** No error found -1 **
!! ERROR: 1 'Unable to f
Hi,
I've attached the sample test8.pl script (smallest one possible that
creates the problem) and a trace file at level 15.
Thanks for any insight,
Joel
dbi_trace.dat
Description: Binary data
test8.pl
Description: Binary data
oel
Ps- we too used PerlBrew to install Perl 5.20 - specifically:
perl 5.20.2
DBI 1.633
DBD::ODBC = 1.50
Martin
20.2
DBI 1.633
DBD::ODBC = 1.50
described previously.
I guessed as much.
2) I (just) tried to get the latest version from git, but I just see
$DBD::ODBC::VERSION = '1.51_4';
from ODBC.pm
I can't seem to find version 1.53_3 at git... I'm not a git expert, so I'll ask
my staff for help to
eviously.
>
> 2) I (just) tried to get the latest version from git, but I just see
>
> $DBD::ODBC::VERSION = '1.51_4';
>
> from ODBC.pm
>
> I can't seem to find version 1.53_3 at git... I'm not a git expert, so
> I'll ask my staff for help to see if the
to get the latest version from git, but I just see
$DBD::ODBC::VERSION = '1.51_4';
from ODBC.pm
I can't seem to find version 1.53_3 at git... I'm not a git expert, so I'll
ask my staff for help to see if they can find 1.53_3 for me.
3) *** I'm using perl 5.10.1 ... m
On 24/03/15 15:45, Joel Plotkin wrote:
Hi,
I have recently ported a large (1.4M line) perl application from:
Centos 6.6
DBI version 1.6.09
DBD::ODBC version 1.23
To:
Centos 6.6
DBI version 1.6.33
DBD::ODBC version 1.50 (and same issue with 1.50_4)
The error doesn't occur in the 1.23 ve
Hi,
I have recently ported a large (1.4M line) perl application from:
Centos 6.6
DBI version 1.6.09
DBD::ODBC version 1.23
To:
Centos 6.6
DBI version 1.6.33
DBD::ODBC version 1.50 (and same issue with 1.50_4)
The error doesn't occur in the 1.23 version, only the later 1.50* versions.
I've just uploaded DBD::ODBC 1.50 to the CPAN. This is the culmination of a
series of 4 development releases in the 1.49 series. There are a number of bug
fixes, enhancements, deprecated features and most importantly some changes in
behaviour. See below for a list of changes.
1.50 2014-
I've just uploaded DBD::ODBC 1.49_3 to the CPAN. Please test it especially if
you've always wanted to use MS SQL Server Query Notification as it should now
support it.
Changes since last full release are:
1.49_3 2014-05-01
[CHANGE IN BEHAVIOUR]
As warned years ago, this relea
I have just uploaded DBD::ODBC 1.47 to the CPAN.
This release does contain significant changes in behaviour for unicode builds
of DBD::ODBC so I hope when I warned you months ago you tested it.
Thanks to everyone on the dbi-dev list and irc that helped me work my way
through the unicode issue
I have uploaded DBD::ODBC 1.46_2 to the CPAN today. As I previously
warned the 1.46_xx series of development releases contain a number of
Unicode fixes. You really should test this as without your feedback it
will be released eventually and these changes are substantial.
The changes since the
On 20/11/13 09:39, Michiel Beijen wrote:
Hi,
I ran into this issue with DBD::ODBC;
I read Martin asked about feedback on the 1.46_1 devel release. I
tested my code against both versions 1.43 and 1.46_1 an the results
are the same.
Thanks for this. It has raised questions that needed
Hi,
I ran into this issue with DBD::ODBC;
I read Martin asked about feedback on the 1.46_1 devel release. I
tested my code against both versions 1.43 and 1.46_1 an the results
are the same.
Basically, if I do
SELECT example FROM foo WHERE example LIKE 'string%';
this is OK as long
On 17/11/2013 08:32, Meir Guttman wrote:
Dear Martin
-Original Message-
From: Martin J. Evans [mailto:boh...@ntlworld.com]
Sent: שבת 16 נובמבר 2013 12:34
To: dbi-users@perl.org; DBI Developers Mailing List; dbi-annou...@perl.org
Subject: DBD::ODBC 1.46_1 released - You REALLY need to
Dear Martin
> -Original Message-
> From: Martin J. Evans [mailto:boh...@ntlworld.com]
> Sent: שבת 16 נובמבר 2013 12:34
> To: dbi-users@perl.org; DBI Developers Mailing List; dbi-annou...@perl.org
> Subject: DBD::ODBC 1.46_1 released - You REALLY need to test this release
I've just uploaded DBD::ODBC 1.46_1 to the CPAN. In the process of
writing
http://www.easysoft.com/developer/languages/perl/sql-server-unicode.html
and https://github.com/mjegh/dbd_odbc_sql_server_unicode I discovered a
serious bug in the way DBD::ODBC can attempt to insert unicode
chara
On 06/11/13 14:36, Jan Holčapek wrote:
Hi Martin,
On Wed, Nov 6, 2013 at 3:05 PM, Martin J. Evans wrote:
I believe this is a bug in your ODBC driver.
I kind of expected that. I'll file a bugreport to Vertica Support.
good, that was part of what I was hoping to achieve when I did
Hi Martin,
On Wed, Nov 6, 2013 at 3:05 PM, Martin J. Evans wrote:
> I believe this is a bug in your ODBC driver.
I kind of expected that. I'll file a bugreport to Vertica Support.
> However, I took the decision in DBD::ODBC to report this an error and some
> might argue differ
On 06/11/13 12:36, Jan Holčapek wrote:
Hi Martin,
3. now run your basic script and send me /tmp/unixodbc.log
attached is the log file you've requested. Please let me know your
findings, thanks!
--Jan
Hi Jan,
Your log shows:
[ODBC][7270][1383740710.126962][SQLExecDirect.c
On 06/11/13 10:57, Jan Holčapek wrote:> Hello there,
I've been using DBD::ODBC to connect to Vertica 6.1 for some time now,
yet updating (quite old 1.23) DBD::ODBC to a recent one (1.45) introduced
an issue. Frankly, I'm not sure if it's really a bug or not.
My environment
Hello there,
I've been using DBD::ODBC to connect to Vertica 6.1 for some time now,
yet updating (quite old 1.23) DBD::ODBC to a recent one (1.45) introduced
an issue. Frankly, I'm not sure if it's really a bug or not.
My environment:
Arch: x86_64
OS: Scientific Linux 6.4
P
I've just uploaded DBD::ODBC 1.45 to the CPAN. As always I'd draw your
attention to a few small changes in behaviour. The changes since 1.43 are
listed below but I need to warn you about an upcoming change first.
WARNING - PLEASE READ:
=
The next development cycle of DBD::ODBC wi
DBD::ODBC moved to github on my account a while ago and now it has moved
again to perl5-dbi group (thanks Merijn [Tux]). After struggling to get
github working on my Windows machine I'm now back in action and I've
done a new development version of DBD::ODBC.
There is one potential
On 27/06/13 13:05, Peter J. Holzer wrote:
On 2013-06-26 14:55:31 -0500, Dan Bent wrote:
$ strace -o strace.log isql -v prod1 user password
usage: [ mid sid level] ...
The strace equivalent to strace is called tusc on HP-UX. I have it
installed in /usr/local/bin which implies that I compiled it
On 2013-06-26 14:55:31 -0500, Dan Bent wrote:
> $ strace -o strace.log isql -v prod1 user password
> usage: [ mid sid level] ...
The strace equivalent to strace is called tusc on HP-UX. I have it
installed in /usr/local/bin which implies that I compiled it myself
(almost exactly 10 years ago), but
database. The developer of our primary
>> business application (developed in COBOL) used Relativity as a
>> reporting/data extract solution. Over the years Liant got acquired by
>> MicroFocus, and for a number of reasons support is difficult to obtain.
>>
>
> Interesting.
TA SOURCES..: /home/dbent/.odbc.ini
# cat /usr/local/liant/etc/odbc.ini
[ODBC Data Sources]
prod1 = Relativity Client
verify = Relativity Client
[prod1]
Driver = /usr/local/liant/lib/relclient.sl
ServerName = chicago.1583
ServerDSN = prod1
QryPlan = 0
ArrayFetc
pplication (developed in COBOL) used Relativity as a
reporting/data extract solution. Over the years Liant got acquired by
MicroFocus, and for a number of reasons support is difficult to obtain.
Interesting. My company do an ODBC driver for ISAM files too.
$ odbcinst -j
unixODBC 2.2
01 PM, Martin J. Evans mailto:boh...@ntlworld.com>> wrote:
On 26/06/2013 19:35, Dan Bent wrote:
Big thanks!
I did this:
ldd
/opt/perl_32/lib/site_perl/5.__8.8/PA-RISC1.1-thread-multi/__auto/DBD/ODBC/ODBC.sl
and got:
/usr/local/liant/lib/l
I have strace, but don't know how to use it.
On Wed, Jun 26, 2013 at 2:01 PM, Martin J. Evans wrote:
> On 26/06/2013 19:35, Dan Bent wrote:
>
>> Big thanks!
>>
>> I did this:
>> ldd
>> /opt/perl_32/lib/site_perl/5.**8.8/PA-RISC1.1-thread-multi/
at it looks for in more than one location is a
candidate for a file that might have been accidentally deleted.
On 06/26/2013 02:35 PM, Dan Bent wrote:
Big thanks!
I did this:
ldd
/opt/perl_32/lib/site_perl/5.8.8/PA-RISC1.1-thread-multi/auto/DBD/ODBC/ODBC.sl
and got:
/usr/local/lian
On 26/06/2013 19:35, Dan Bent wrote:
Big thanks!
I did this:
ldd
/opt/perl_32/lib/site_perl/5.8.8/PA-RISC1.1-thread-multi/auto/DBD/ODBC/ODBC.sl
and got:
/usr/local/liant/lib/libodbc.sl.1 =>/usr/local/liant/lib/libodbc.sl.1
/usr/lib/libc.2 => /usr/lib/libc.2
Big thanks!
I did this:
ldd
/opt/perl_32/lib/site_perl/5.8.8/PA-RISC1.1-thread-multi/auto/DBD/ODBC/ODBC.sl
and got:
/usr/local/liant/lib/libodbc.sl.1 =>/usr/local/liant/lib/libodbc.sl.1
/usr/lib/libc.2 => /usr/lib/libc.2
/usr/lib/libdld.2 =>/usr/lib
On 26/06/2013 18:42, Dan Bent wrote:
I agree, and I've been trying to identify what changed yesterday morning.
The database, Perl,and the program all reside on the same machine, so I
think we can rule out network issues.
As far as I know, the DBMS, Perl and ODBC infrastructure have been
s
I agree, and I've been trying to identify what changed yesterday morning.
The database, Perl,and the program all reside on the same machine, so I
think we can rule out network issues.
As far as I know, the DBMS, Perl and ODBC infrastructure have been stable
for quite a while, and I ha
On 26/06/2013 17:28, Dan Bent wrote:
I suddenly lost the ability to connect to my ODBC database yesterday,
after years of using the same function to establish a connection:
sub dbaseconnect {
if (defined($testing)) {
if ($testing eq "YES") {
$dsn = '
Big thanks for the rapid response!
non-Perl ODBC tools? I'm not sure. I've been working with Perl for a
number of years and may have tools I am not aware of.
I do have Windows users who access the same database without any issues,
but I don't know of any tools I have in UNIX oth
On Wed, Jun 26, 2013 at 9:28 AM, Dan Bent wrote:
> I suddenly lost the ability to connect to my ODBC database yesterday,
> after years of using the same function to establish a connection:
>
So, the question you must ask yourself is:
What changed yesterday? Or, if not yesterday,
On 6/26/2013 9:28 AM, Dan Bent wrote:
and the program just hangs when it looks for data sources using the
ODBC driver. So, I suspect that there are issues with the ODBC driver.
Here are the versions of the various DBI module components:
do you have any non-perl ODBC tools? I suspect (purely
I suddenly lost the ability to connect to my ODBC database yesterday, after
years of using the same function to establish a connection:
sub dbaseconnect {
if (defined($testing)) {
if ($testing eq "YES") {
$dsn = 'dbi:ODBC:test1' ;
print &q
I've just uploaded DBD::ODBC 1.42_5 to CPAN. I'm hoping this is going to be the
final development release of the 1.42 series. If you rely on DBD::ODBC then
please test it. The changes since the last full release are below. In
particular note that there is a small change in behaviou
I have just uploaded DBD::ODBC 1.41 to the CPAN.
This is the full release of the 1.40 development series and the changes can be
found below. I draw your attention to a number of changes in behaviour. Thank
you to all contributors.
=head2 Changes in DBD::ODBC 1.41 October 23 2012
A full
I will probably release this as 1.41 in the next week. Please note the
changes in behaviour.
=head2 Changes in DBD::ODBC 1.40_3 October 8 2012
[BUG FIXES]
Oops, changes to some rt tests fail when not run to MS SQL Server
and they should not be run for other drivers - there was a double
On 28/09/2012 23:54, Jeff Tate wrote:
I have got back to the task. I have installed an openSUSE virtual
machine (matches the production server) and then installed Teradata
GSS, ICU, CLIV2 and ODBC -packages. I have verified that the drivers
function by installing the Teradata navigator and
I have got back to the task. I have installed an openSUSE virtual machine
(matches the production server) and then installed Teradata GSS, ICU, CLIV2
and ODBC -packages. I have verified that the drivers function by installing
the Teradata navigator and successfully getting data over ODBC.
This
I've just uploaded DBD::ODBC 1.40_2 to the CPAN. Please give it a test,
especially if you rely on it and there have been some significant binding
changes:
=head2 Changes in DBD::ODBC 1.40_2 September 6 2012
[MISCELLANEOUS]
New test cases added for some rts.
Added Test::NoWarnin
Hi,
as requested in the unit tests, I'm here attaching my results for
DBD::ODBC's t/ExecuteArray.pm tests in combination with sqlite3odbc.
I *know* it is probably not very useful to use DBD::ODBC in
combination with SQLite, as there is already a dedicated DBI driver,
but I chose this
dbi-users@perl.org
> Subject: Re: Help please with DBD::ODBC on SUSE-Linux
>
> On 15/08/2012 18:25, Jeff Tate wrote:
> >
> > Step 1) added ODBC trace information to odbcinst.ini (made my own
> > copy (system file)) and change $ODBCINST to address
> >
> >
On 15/08/2012 18:25, Jeff Tate wrote:
Step 1) added ODBC trace information to odbcinst.ini (made my own
copy (system file)) and change $ODBCINST to address
NO output produced in trace file
That suggests you are NOT using unixODBC as the ODBC driver manager.
Therefore this
On 15/08/2012 18:25, Jeff Tate wrote:
Step 1) added ODBC trace information to odbcinst.ini (made my own copy
(system file)) and change $ODBCINST to address
NO output produced in trace file
Step 2) running test under gdb
Linux:puTest> gdb `which perl`
GNU gdb (GDB) S
Step 1) added ODBC trace information to odbcinst.ini (made my own copy
(system file)) and change $ODBCINST to address
NO output produced in trace file
Step 2) running test under gdb
Linux:puTest> gdb `which perl`
GNU gdb (GDB) SUSE (7.3-0.6.1)
Copyright (C) 2011 F
On 15/08/12 15:32, Jeff Tate wrote:
Couldn't find odbcinst. Compiled test code as instructed. Result of a.out
is:
size of SQLLEN is 8
Ok, so this /should be/ good. It means that compiling DBD::ODBC with those
header files means SQLLEN and SQLULEN are 8 bytes in size and one /would
RE: Help please with DBD::ODBC on SUSE-Linux
Couldn't find odbcinst. Compiled test code as instructed. Result of a.out
is:
size of SQLLEN is 8
As for decision to install Teradata odbc rather than SUSE odbc, that was
made by the sysadmin team. I am just a user. I will however ask them if
th
Couldn't find odbcinst. Compiled test code as instructed. Result of a.out
is:
size of SQLLEN is 8
As for decision to install Teradata odbc rather than SUSE odbc, that was
made by the sysadmin team. I am just a user. I will however ask them if
there is the possibility to install uni
On 14/08/12 19:05, Jeff Tate wrote:
I am trying to build a private perl with ODBC connection to a
Teradata database on SUSE-Linux. Perl build with no errors, DBI
installed clean, DBD::ODBC compiles seemingly cleanly, but fails
almost all the tests. So, help will be gratefully accepted.
The
I am trying to build a private perl with ODBC connection to a Teradata
database on SUSE-Linux. Perl build with no errors, DBI installed clean,
DBD::ODBC compiles seemingly cleanly, but fails almost all the tests. So,
help will be gratefully accepted.
The attached shows:
. Relevant
On 08/08/12 16:24, Manikantan, Madhunapanthula_Naaga wrote:
Hello Evans,
I am using Class::DBI::Sybase::set_up_table method. It fails with the below
error.
DBD::ODBC::st execute failed: [unixODBC][Driver Manager]Function sequence error
(SQL-HY010) at /u/manikanm/column_info_test.pl
I debugged
I've just sent to the CPAN the 1.39 release of DBD::ODBC. This contains
some bug fixes, one major enhancement to support TAF and one change in
behaviour you should note.
=head2 Changes in DBD::ODBC 1.39 July 7 2012
[BUG FIXES]
Manifest mentioned 2 files in examples which do not exist -
I have uploaded DBD::ODBC 1.38_3 to CPAN. As no new issues have been
reported my intention is to make this a full 1.39 in the next week or
so. There is nothing too exciting in 1.38_3 but the previous 1.38
development releases contain some interesting enhancements and changes.
Please let me
Hi,
I am currently using the trial version of the Easysoft ODBC-SQL Server driver.
I need to be able to connect from Perl to SQL Server using a Linux machine and
am currently using DBI version 1.607. I was hoping someone could tell me which
versions of the DBD::ODBC and ODBC-SQL Server driver
, whenever I run the example script given to connect to the SQL Server DB, the
compiler gives me an error on the "use DBI" line saying that that current
system is not using the right DBI version. I wasn't sure if that was because the DBD or
the ODBC driver wasn't compatibl
tin
> > Well, whenever I run the example script given to connect to the SQL Server
> > DB, the compiler gives me an error on the "use DBI" line saying that that
> > current system is not using the right DBI version. I wasn't sure if that
> > was because the D
t;use DBI" line saying that that current
system is not using the right DBI version. I wasn't sure if that was because the DBD or
the ODBC driver wasn't compatible with v1.607 and the description on the website for both
these modules does not really state which DBI is needed. I was
t that current
system is not using the right DBI version. I wasn't sure if that was because
the DBD or the ODBC driver wasn't compatible with v1.607 and the description on
the website for both these modules does not really state which DBI is needed. I
was using DBD-ODBC-1.33 and odbc-sqlserver-1.4.27 for the ODBC driver.
Oops, forgot to post this to the list.
Martin
--- Begin Message ---
On 18/06/2012 21:51, Shrenuj Bansal wrote:
Hi,
I am currently using the trial version of the Easysoft ODBC-SQL Server driver.
I need to be able to connect from Perl to SQL Server using a Linux machine and
am currently using
Hi,
I am currently using the trial version of the Easysoft ODBC-SQL Server driver.
I need to be able to connect from Perl to SQL Server using a Linux machine and
am currently using DBI version 1.607. I was hoping someone could tell me which
versions of the DBD::ODBC and ODBC-SQL Server driver
Forwarding to DBI-dev , DBI-users as an fyi.
Thanks
_
From: Manikantan, Madhunapanthula_Naaga
Sent: Friday, June 01, 2012 5:02 PM
To: 'Martin J. Evans'
Subject: DBD::ODBC {ChopBlanks=>1} option issue
Hello Martin,
I hope you a
antan, Madhunapanthula_Naaga
Sent: Friday, June 01, 2012 5:02 PM
To: 'Martin J. Evans'
Subject: DBD::ODBC {ChopBlanks=>1} option issue
Hello Martin,
I hope you are doing well.
ChopBlanks option, doesn't seem to work with DBD::ODBC. Can you please help?
I checked out latest version of DBD::ODB
For some reason I announced 1.38_1 on my blog and forgot to do it here. 1.38_1
contains some changes in behaviour wrt binding of columns. If you rely on
DBD::ODBC you should test this development release now.
1.38_2 adds support for Oracle TAF so long as you are using the Easysoft Oracle
ODBC
As a result of a thread in the dvi-dev list I am proposing a change to
the way DBD::ODBC binds columns.
The changes are:
1. Columns described as SQL_INTEGER will be bound as SQL_C_LONG and
hence retrieved as a C long and the bound scalar will be set using
sv_setiv. This means the bound
On 19/05/2012 13:33, pe...@vanroose.be wrote:
DBD::ODBC is returning strings for integers. This results in incorrect values
for bit wise operators. (for ex:- $e='16'; $f = '32' print $e& $f returns
12 instead of zero ). Is there a setting that can help us retu
> DBD::ODBC is returning strings for integers. This results in incorrect values
> for bit wise operators. (for ex:- $e='16'; $f = '32' print $e & $f returns
> 12 instead of zero ). Is there a setting that can help us return integers as
> 'integers
Hello Evans/DBi-users,
DBD::ODBC is returning strings for integers. This results in incorrect values
for bit wise operators. (for ex:- $e='16'; $f = '32' print $e & $f returns
12 instead of zero ). Is there a setting that can help us return integers as
'in
I've just uploaded DBD::ODBC 1.35 to CPAN.
This is the culmination of 7 development releases in the 1.34 chain and
is a significant release containing a lot of changes and enhancements.
As always I would like to thank everyone who has helped and especially
CPAN testers. The full li
I've just uploaded DBD::ODBC 1.34_5 to the CPAN.
I know I often say this but my intention is to release this as 1.35 soon unless
any major issues are found. The total changes since the last full release are:
=head2 Changes in DBD::ODBC 1.34_5 February 17 2012
[BUG FIXES]
t;... in DBI.pm
Tim.
Thanks,
I've made that change, checked it and uploaded DBD::ODBC 1.34_4.
Martin
1 - 100 of 1812 matches
Mail list logo
