Re: DBD::Sybase building Problem 6432bit
Hi, So the issue is that the 64 bit libraries are not found at run-time. If you source the SYBASE.sh file located in the root directory of your ASE 15.7 64 bit install you should be fine. You can also add these directories to the /etc/ld.so.conf to add these directories to the normal search path. On a CentOS box I have: [mpeppler@li ~]$ cat /etc/ld.so.conf include ld.so.conf.d/*.conf [mpeppler@li ~]$ cat /etc/ld.so.conf.d/ mysql-x86_64.conf sybase.conf [mpeppler@li ~]$ cat /etc/ld.so.conf.d/sybase.conf /opt/sybase/ASE-15_0/lib /opt/sybase/OCS-15_0/lib [mpeppler@li ~]$ Michael On 16 Oct 2014, at 19:13, Monetron Team deve...@monetron.com wrote: Hello List, My problem is that i have a 32 bit version of ASE/ OpenClient, but as it is running on 64bit Linux, Perl is installed in 64 bit mode. # uname -a Linux 2.6.18-398.el5xen #1 SMP Tue Sep 16 21:31:50 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux # perl -v This is perl, v5.8.8 built for x86_64-linux-thread-multi # Sybase ASE 15.0 32 bit $SYBASE /opt/sybase/ase-15 I have downloaded ASE 15.7 64bit and exported $SYBASE with the path to the 64bit OCS folder. first i tested with isql if the connection parameters in PWD-File are oK. then i started to build DBD::SYBASE and the make test, resulted in a lot of errors Please see attached log file i hope that someone here can help me, as i saw that the sybperl - peppler list is not active.. thanks in advance Uwe logfile.txt -- Michael Peppler Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html A successful [software] tool is one that was used to do something undreamed of by its author. -- S. C. Johnson
Re: Using 64 bit DBD with Sybase 15
On Feb 11, 2013, at 11:19 PM, Terence J. young, DC wrote: Hi, The default date format for the 64 bit version may be different than the 32 bit. I'll just re-iterate that this is not a 64 vs 32 bit issue, but rather a 12.x vs 15.x, or 15.0.x vs 15.7 issue. I tried the OPs issue on a 32bit version of OC 15.7, and had the same behavior. to compensate for this, I always set the default date format in my login subroutine. (outside of these options, I use the convert function in sybase) Which is not a bad idea. On 2/7/13 9:53 AM, Gerardi, Mark wrote: Has anyone had the chance to use the 64 bit versions of DBD Sybase using dates/times? I'm pulling out a date from Sybase 15, with the latest version of ctlib, and getting weird results. By weird, I mean the date field (defined as date in the database), returns Jan 4 2013 12:00am as Jan 4 2013. A field (defined as time in the database), returns Jan 1 1900 5:00pm as 5:00pm. In 32 bit, the dates return as Jan 4 2013 12:00am and Jan 1 1900 5:00pm respectively. This same function works fine on the 32 bit side. It does work properly if a convert(char(20, date) is used in the query, but we don't want to change the code if possible. Without the convert, it is just pulling the date from a date column is chopping off the time when it is midnight. Also, if the date is 1/1/1900, its only outputting the time, without the date at all. We've tried multiple versions of DBD, still no luck. Any suggestions? I’m using DBD version 1.622 btw… Thanks! Mark Gerardi | Senior Software Engineer -- Michael Peppler Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html A successful [software] tool is one that was used to do something undreamed of by its author. -- S. C. Johnson
Re: (Fwd) Sybase 15.0
Hi Tom, DBI itself has no control over this. It's DBD::Sybase, and more precisely what DBD::Sybase tells OpenClient to do. You need to rebuild your DBD::Sybase binary with the 15.x OpenClient installation, and you need to use a version of DBD::Sybase that is recent enough to understand CS_VERSION_150 or CS_VERSION_CURRENT (1.09 or later, I believe). Michael On Aug 20, 2011, at 12:43 PM, Tim Bunce wrote: - Forwarded message from Mackin, Thomas E. thomas.mac...@lfg.com - Date: Fri, 19 Aug 2011 14:33:11 -0400 From: Mackin, Thomas E. thomas.mac...@lfg.com To: tim.bu...@pobox.com Subject: Sybase 15.0 Tim, We migrated our Sybase database (AIX) to 15.0.2 about 2 years ago. We also use Open Client 15.0 and everything works, mostly. We have been butting up against the 30 character limit for object names when running scripts through Perl (5.6) ever since. Most of the time we simply rename things to be 30 characters or less. This is now becoming somewhat of a pain. Is it possible to recompile/tweak/modify something in the Perl DBI code to get around this? Keep in mind that I am NOT a Perl developer (he left!) but am tasked with trying to get this fixed. We found some C code that uses Sybase.h, and we assume that somewhere in all that is the datatype restriction that limits the object names to 30 characters. Can a newer header file be used to recompile the dll or am I barking up the wrong tree? Any help or direction you could give us would be great. Surely someone has Sybase 15.0 and Perl 5.6 working with long object names... Thanks, Tom Mackin --- Lincoln Financial Group Investments, IA, and Risk Management IT Application Systems Analysis Programming Lead [1]thomas.mac...@lfg.com 260.455.1466 Mailstop: 2C12 Notice of Confidentiality: **This E-mail and any of its attachments may contain Lincoln National Corporation proprietary information, which is privileged, confidential, or subject to copyright belonging to the Lincoln National Corporation family of companies. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. Thank You.** References Visible links 1. mailto:thomas.mac...@lfg.com - End forwarded message - -- Michael Peppler Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html A successful [software] tool is one that was used to do something undreamed of by its author. -- S. C. Johnson
Re: DBD::Sybase charset error change
There was a change in 1.11 (I think) to handle utf8/unicode data. THis
included forcing the charset to utf8 in the client.
You can go back to the old behavior if you edit dbdimp.c and change or
comment out the following:
if (retcode == CS_SUCCEED) {
if ((retcode = cs_locale(context, CS_SET, locale,
CS_SYB_CHARSET,
utf8, CS_NULLTERM, NULL)) != CS_SUCCEED) {
warn(cs_locale(CS_SYB_CHARSET) failed);
}
}
in the syb_init() call.
I'll need to review that decision to see how to make it work for both
unicode and non-unicode data.
Michael
On Tue, Aug 9, 2011 at 2:58 AM, Douglas Wilson
douglasg.wil...@gmail.com wrote:
I'm using perl 5.8.8 with DBD::Sybase 1.09, and the SQL statement
below appears to prepare and execute fine, but I've also just compiled
a perl 5.14.1 with DBD::Sybase 1.12, and with the newer versions I get
the following error on prepare:
DBD::Sybase::db prepare failed: Server message number=2401 severity=11
state=2 line=0 server=TESTASE text=Character set conversion is not
available between client character set 'utf8' and server character set
'iso_1'.
Server message number=2411 severity=10 state=1 line=0 server=TESTASE
text=No conversions will be done.
If I add ';charset=iso_1' to the dsn string on connect, then
everything seems to work ok. I'm just wondering what changed the
behavior (perl? DBD::Sybase?), and if I've handled it correctly or
done something else wrong...
Thanks...
my $upd_sql = SQL;
UPDATE my_table
SET
group_nbr = ?, last_ch_user = user, last_ch_date = getdate()
WHERE primary_id = ?
AND source_id = 100
SQL
Re: DBD::Sybase and DBI-get_info()
On Jun 3, 2011, at 9:58 PM, eric.b...@barclayscapital.com
eric.b...@barclayscapital.com wrote:
Thanks, John.
If anyone can comment with authority on the lack of intraspection
capabilities in DBD::Sybase, that'd be helpful. I looked through the code as
well, and didn't find anything to say one way or another. Get_info() appears
to be relatively new to DBI, and it look slike there is some facility to
generate the code required to populate get_info() for your DBD's, but nothing
that says one way or another if there is actually any way to get info form
the driver.
Hoping someone can help here. We are currently running DBD::Sybase for
Sybase and moving toward using DBD::ODBC for MSSQL instead of using FreeTDS
under DBD::Sybase for MS SQL. IN any case, it would be particularly helpful
if we could ask the driver object what type of DB it's a connection handle to.
There are a couple of things you could try - maybe see if any of the
private/driver specific methods are available.
Or something like $dbh-{syb_oc_version}, which if it returns something will at
least identify the driver handle as being a DBD::Sybase handle using Sybase
OpenClient. If you are using DBD::Sybase with FreeTDS then you may need to use
another private attribute, maybe something like
defined($dbh-{syb_dyn_supported}).
Michael
--
Michael Peppler
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
A successful [software] tool is one that was used to do something undreamed of
by its author. -- S. C. Johnson
Re: Unicode and Sybase univarchar
Hi,
Which version of Sybase, which version of Sybase OpenClient, and which version
of DBD::Sybase?
Are you setting the connection charset to utf8 (in the connect() call?)
Thanks,
Michael
On Jun 3, 2010, at 5:22 PM, Dave Rolsky wrote:
I'm working on an i18n project, and we use Sybase (sigh).
Newer versions of Sybase have built-in support for Unicode with the
univarchar (and other uni*) type.
However, it seems like DBD::Sybase doesn't have any support for this.
Specifically, if I take a Perl unicode string (utf8 flag is on) and insert it
in a univarchar column, it seems to be inserted as raw bytes (or something).
What's really bizarre is that when I select the value back I get something
like 0065006d00200064006100730068003a002000e200800094.
Yes, that's a literal string containing a series of 2-digit hex numbers!
I can translate this back to Perl unicode with this madness:
my $chars = do {
use bytes;
join q{}, map { chr( eval '0x' . $_ ) } $fromdb =~ /()/g;
};
my $unicode = decode( 'utf8', $chars );
So the data is there, but not in a very usable form.
Has anyone researched or solved this problem?
Michael Peppler, if you're reading this, is there any work on supporting
Perl's unicode format transparently in DBD::Sybase?
My employer might be able to pay to have this work done, if you're
interested. Alternately, maybe you could give me some hints and I could try
to figure it out.
-dave
/*
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
*/
--
Michael Peppler
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
A successful [software] tool is one that was used to do something undreamed of
by its author. -- S. C. Johnson
Re: Unicode and Sybase univarchar
On Jun 3, 2010, at 7:29 PM, Michael Peppler wrote:
Hi,
Which version of Sybase, which version of Sybase OpenClient, and which
version of DBD::Sybase?
Are you setting the connection charset to utf8 (in the connect() call?)
I just gave this a try - I'm under linux, with ASE 15.5. I created a table with
a univarchar column, entered some data via isql, then wrote a minimal perl
script to fetch the data.
If I use a UTF8 locale (i.e. LANG=en_us.UTF8) I get the correct output.
If I don't I do not get the correct output, at least for rows where non-ascii
data has been entered into the table.
I'm using DBD::Sybase 1.10.
Michael
On Jun 3, 2010, at 5:22 PM, Dave Rolsky wrote:
I'm working on an i18n project, and we use Sybase (sigh).
Newer versions of Sybase have built-in support for Unicode with the
univarchar (and other uni*) type.
However, it seems like DBD::Sybase doesn't have any support for this.
Specifically, if I take a Perl unicode string (utf8 flag is on) and insert
it in a univarchar column, it seems to be inserted as raw bytes (or
something).
What's really bizarre is that when I select the value back I get something
like 0065006d00200064006100730068003a002000e200800094.
Yes, that's a literal string containing a series of 2-digit hex numbers!
I can translate this back to Perl unicode with this madness:
my $chars = do {
use bytes;
join q{}, map { chr( eval '0x' . $_ ) } $fromdb =~ /()/g;
};
my $unicode = decode( 'utf8', $chars );
So the data is there, but not in a very usable form.
Has anyone researched or solved this problem?
Michael Peppler, if you're reading this, is there any work on supporting
Perl's unicode format transparently in DBD::Sybase?
My employer might be able to pay to have this work done, if you're
interested. Alternately, maybe you could give me some hints and I could try
to figure it out.
-dave
/*
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
*/
--
Michael Peppler
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
A successful [software] tool is one that was used to do something undreamed
of by its author. -- S. C. Johnson
--
Michael Peppler
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
A successful [software] tool is one that was used to do something undreamed of
by its author. -- S. C. Johnson
Re: Unicode and Sybase univarchar
On Jun 3, 2010, at 8:14 PM, Dave Rolsky wrote: On Thu, 3 Jun 2010, Michael Peppler wrote: Which version of Sybase, which version of Sybase OpenClient, and which version of DBD::Sybase? Ah, I was using the old libs (11.0), which may have been the problem. I was also using DBD::Sybase 1.07. I switch to Sybase 15.0 (OCS 15.0 if that makes sense), OpenClient 15.0 libs, and DBD::Sybase 1.10. Now it's closer to working. If I set charset=utf8 in the dsn, I get 2010/06/03 14:08:11 unicode CRITICAL: FATAL: DBD::Sybase::db do failed: Server message number=2402 severity=16 state=1 line=1 server=HDATADEV1 text=Error converting characters into server's character set. Some character(s) could not be converted. I'm not sure what that means. Hmmm - is that on a query, or on an insert operation? If I _don't_ set that, the data goes in and comes out as bytes, rather than the bizarro hex string. However, the data does have the utf8 flag set when it comes back from Sybase, so I have to run it through Encode::decode. I really don't think I can realistically tell the bazillion developers here just run all the data through Encode. I'd really like see an end-to-end solution. I agree - I've just not had much opportunity (or requests) to ensure that this works 100%. Ideally if you could send me some sample code, and a simple table structure and data that reproduces the problem for you I could try to look at it and see if I can fix it. Also, it's not clear to me that the data is actually being stored as characters at the Sybase level. I'm not even sure how I'd figure this out. When I do a select from sqsh, I see the wacky hex string, but I can't tell if that's Sybase trying to present data to me in a format it thinks my environment can handle. When in doubt - use the Sybase tools (i.e. isql, and use -Jutf8 to force conversion to/from utf8 when reading/writing the data). You can also do a convert(varbinary, the_univarchar_col) to see the hex representation of the data in the database. Basically, what I need is to be able to take Perl native unicode strings, store them in Sybase in Sybase's native format (utf16, I believe), and then retrieve them as Perl native unicode strings again. If you store data in univarchar, etc columns, then it's utf16. You can also set up the dataserver to use utf8 throughout - but that's something you'd have to discuss with your DBAs. Michael -- Michael Peppler Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html A successful [software] tool is one that was used to do something undreamed of by its author. -- S. C. Johnson
Re: using DBI for mutual exclusion across multiple servers
OK - now I'm *really* late for this
But for Sybase you'll have to make sure that the table is created in datarows
locking if you want to use this technique - otherwise the update will lock the
entire page, and you won't have the granularity that you wish for.
The actual update/commit will be very cheap as your table fits on a single page.
As Sybase doesn't do multi-version concurrency the update simply writes the new
page to the log. I would use a rollback instead of a commit here, as that will
simply invalidate the log page rather than copying the new log page to the
actual location of the table.
Note that if you have to connect() to the dataserver each time you need to set
the mutex the connect() overhead will be much worse than the actual update
Michael
On Feb 13, 2010, at 12:57 AM, Jonathan Swartz wrote:
I need to guarantee that only one process at a time enters a subroutine foo()
for a particular argument.
That is, if one process is in a call to foo(1), another call to foo(1) will
block, but a call to foo(2) could proceed.
This needs to be guaranteed across multiple servers, as the calls to foo()
manipulate multiple shared objects in the database.
Even though foo() isn't directly associated with one database table (and thus
I can't rely on database transactions directly), I figured I could use the
database to enforce the mutexes.
My idea was to create a mutexes table with, say, 1024 rows:
create table mutexes (id int);
insert into mutexes values (0);
...
insert into mutexes values (1023);
Then on a call to foo, I hash the argument to an integer in 0..1023 and
reserve that row with an dummy update:
sub foo {
my ($id) = @_;
my $hash = $id % 1024;
my $dbh = DBI-connect(..., AutoCommit = 0);
$dbh-prepare(update mutexes set id = ? where id = ?, $hash, $hash);
... # mutual exclusion guaranteed in here
$dbh-commit(); # or $dbh-rollback() - not sure which is cheaper
}
I'm aware of the deadlocking potential of mutexes, but will avoid that by
only reserving one row per process at a time. I'm also aware that some
unnecessary serialization may occur due to hash collisions, but I'm not too
worried about it and can always increase the # buckets if needed.
This seems to work in testing. Just wanted to find out if it makes sense, if
there's a CPAN module that already does this (couldn't find one), or if there
are problems that could cause this to blow up.
Thanks!
Jon
--
Michael Peppler
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
A successful [software] tool is one that was used to do something undreamed of
by its author. -- S. C. Johnson
Re: dbi-link with Sybase
It's hard to tell for sure what could be wrong.
First, I would try to check that the Sybase related env. variable are
correctly seen when you are in the dbi-link script.
Second - you may run into an insurmountable problem: Sybase open
client installs its own signal handler to do a number of things
(timeouts, among others). This signal handler is incompatible with the
signal handler that perl installs for itself since 5.8.x or
thereabouts, and causes various issues depending on which combination
of modules you try to use.
I assume that you compiled DBD::Sybase with the non-threaded
libraries, as is recommended, right?
Michael
On Sat, Dec 26, 2009 at 11:23 PM, ferna...@lozano.eti.br wrote:
Hi there,
This may not be the best list for my question, but I'm sure someone there
will he able to help me
;-)
I'm trying to use dbi-link under RHEL5.3. Using PostgreSQL and Perl rpms from
distro, installed
Sybase ASE 1.5.5 developers edition and DBD::Sybase using cpan -i.
My test programs, using pubs2 example database, work fine. They connect as:
$dbh = DBI-connect(dbi:Sybase:server=RHEL53I386, teste, 123testando);
So I have a working DBD::Sybase install. But then I try to initialize
dbi-link using the statement:
SELECT make_accessor_functions(
'dbi:Sybase:server=RHEL53I386',
'teste',
'123testando',
'---
AutoCommit: 1
RaiseError: 1
',
NULL,
NULL,
NULL,
'pubs2'
);
I get the error (from postgresql logs)
OpenClient message: LAYER = (7) ORIGIN = (2) SEVERITY = (6) NUMBER = (6)
Message String: ct_con_alloc(): unable to get layer message string: unable to
ge
t origin message string: error string not available
NOTICE: ct_con_alloc failed at
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread
-multi/DBD/Sybase.pm line 92.
CONTEXT: SQL statement SELECT dbi_link.cache_connection( 1 )
SQL statement SELECT dbi_link.create_accessor_methods(
'pubs2',
NULL,
NULL,
'dbi:Sybase:server=RHEL53I386',
'teste',
'123testando',
1
)
ERROR: error from Perl function: error from Perl function: error from Perl
func
tion: DBI connect('server=RHEL53I386','teste',...) failed: (no error string)
at
line 137 at line 36. at line 53.
I already tried forcing my database to en_US.UTF-8 and sourced SYBASE.sh from
postgres bash_profile
script. Before that, the error was aboit missing dynamic libs.
I know this looks more a postgresql / dbi-link thing than a dbi thing but
maybe someone can
understand the sybase error message and help me.
[]s, Fernando Lozano
Re: DBD::Sybase charset issue connecting to MS-SQL
On May 6, 2009, at 10:06 PM, Peter Thoeny wrote:
Hi,
I stumbled on a roadblock and need some help.
I am trying to connect to a MS-SQL database using DBD::Sybase, http://search.cpan.org/~mewp/DBD-Sybase-1.09/dbd-sybase.pod
on Centos 5.2. The DBD::Sybase module is used from within the
DatabasePlugin of the TWiki Enterprise Collaboration Platform.
Connection works fine unless there are special characters such as
single quotes in the query result. With special characters, I get
this message: Some character(s) could not be converted into
client's character set. Unconverted bytes were changed to question
marks ('?').
If your client runs on CentOS it will most likely run in ISO8859-1 or
in UTF-8.
The MS special chars are in CP1252, but not in ISO8859-1.
Setting the charset= attribute at the connection level is supported by
DBD::Sybase which simply hands this information off to the underlying
library. When using Sybase ClientLibrary the charsets are well-
defined, and you could specify cp1252 to tell OpenClient not to
perform any conversions.
I don't know how FreeTDS handles the charset conversions - you may
wish to post this to the freetds mailing list to get a better answer.
Michael
--
Michael Peppler -Peppler Consulting
SaRL
mpepp...@peppler.org - http://www.peppler.org
Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com
Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: DBD::Sybase 1.09 build error on perl 5.10.0
, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-D_REENTRANT -I/usr/local/include' ccversion='Sun C 5.8 2005/10/13', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro_11/prod/lib/v8plus -L/opt/SUNWspro_11/prod/lib -L/lib -L/usr/local/lib ' libpth=/usr/lib /usr/ccs/lib /opt/SUNWspro_11/prod/lib/v8plus /opt/SUNWspro_11/prod/lib /lib /usr/local/lib libs=-lsocket -lnsl -ldl -lm -lpthread -lc perllibs=-lsocket -lnsl -ldl -lm -lpthread -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-KPIC', lddlflags='-G -L/usr/lib -L/usr/ccs/lib -L/opt/SUNWspro_11/prod/lib/v8plus -L/opt/SUNWspro_11/prod/lib -L/lib -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under solaris Compiled at Dec 28 2008 00:07:21 %ENV: PERL5LIB=/sa/common/lib/5.10.0 @INC: /sa/common/lib/5.10.0/sun4-solaris-thread-multi /sa/common/lib/5.10.0 /home/persicom/perl.v5.10.0/lib/5.10.0/sun4-solaris-thread-multi /home/persicom/perl.v5.10.0/lib/5.10.0 /home/persicom/perl.v5.10.0/lib/site_perl/5.10.0/sun4-solaris- thread-multi /home/persicom/perl.v5.10.0/lib/site_perl/5.10.0 . -- Matthew O. Persico Michael Peppler -Peppler Consulting SaRL mpepp...@peppler.org - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: ct_finish_send error when updating text w sybase
On Aug 1, 2008, at 10:42 PM, joe wrote: Hello, can anyone tell me why i am unable to update the text with this function. I get select DESCRIP from WEB_ISSUES where ISSUE_ID = '1217617351-999885' Can't locate object method ct_finish_send via package DBI::st at ./ web_issues.cgi line 102. Rats - there's a typo in the man page. Try $sth-syb_ct_finish_send() instead. Michael -- Michael Peppler -Peppler Consulting SaRL [EMAIL PROTECTED] - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: No line number with RaiseError in DBD::Sybase
Douglas Wilson wrote:
On Thu, Jun 19, 2008 at 1:53 PM, Tim Bunce [EMAIL PROTECTED] wrote:
On Wed, Jun 18, 2008 at 02:14:06PM -0700, Douglas Wilson wrote:
With RaiseError or PrintError set, if DBD::Sybase throws an error, the
error message does not indicate what line number of the program that the
error was on ... or what program/module that the error was in.
I'd guess that that's because sybase error messages tend to end with a
newline character.
Hopefully that's a simple fix for Michael to get into the next release.
You could always send a patch to help out...
Once I found the magic spot, this is the simplest thing I can think of (there
is a lot of conditional concatenating in that function, and some of the
concatenations include newlines):
*** ../DBD-Sybase-1.08/dbdimp.c Thu Apr 19 11:31:19 2007
--- dbdimp.cThu Jun 19 14:09:45 2008
***
*** 545,550
--- 545,551
else
retcode = CS_SUCCEED;
+ sv_catpv(DBIc_ERRSTR(imp_dbh), );
return retcode;
} else {
if(srvmsg-msgnumber) {
Thanks - I'll get that into the next release.
Michael
--
Michael Peppler - Peppler Consulting SaRL
[EMAIL PROTECTED] - http://www.peppler.org
Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com
Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: Unable to install DBD:Sybase-1.08 on my AIX 5.2 server with Perl 5.8.0 DBI-1.43
Martin Mann wrote: I did the upgrade to DBI-1.604 and this time DBD:Sybase-1.08 fails during make with a different error but an error non the less... Any help would be greatly appreciated... dbdimp.c, line 800.23: 1506-045 (S) Undeclared identifier BLK_VERSION_150. dbdimp.c, line 804.23: 1506-045 (S) Undeclared identifier BLK_VERSION_125. dbdimp.c, line 808.23: 1506-045 (S) Undeclared identifier BLK_VERSION_120. make: 1254-004 The error code from the last command is 1. Those symbols are missing from the FreeTDS include files. Edit dbdimp.c, and somewhere near the top add: #define BLK_VERSION_150 BLK_VERSION_100 #define BLK_VERSION_125 BLK_VERSION_100 #define BLK_VERSION_120 BLK_VERSION_100 Michael -- Michael Peppler - Peppler Consulting SaRL [EMAIL PROTECTED] - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: Error in DBD::Sybase 1.08 handling of severe 5702 error
Tim Bunce wrote: I just ran into this problem... A stored procedure call like exec foo ... was appearing to succeed but returning no data. It turned out that the ASE (15.0, which we've recently upgraded to) was terminating the backend process (not sure why yet) but DBD::Sybase 1.08 wasn't noticing it. Here's the trace: - execute for DBD::Sybase::st (DBI::st=HASH(0x2a995b0360)~0x2a995b04b0) syb_alloc_cmd() - CS_COMMAND 294e7e0 for CS_CONNECTION 294b8e0 cmd_execute() - ct_command() OK cmd_execute() - ct_send() OK cmd_execute() - set inUse flag servermsg_cb - number=5702 severity=10 state=1 line=2 server=dev_barbie01 text=ASE is terminating this process. st_next_result() - ct_results(4047) == 1 st_next_result() - ct_results(4046) == 1 ct_results(4046) final retcode = -205 st_next_result() - lasterr = 0, lastsev = 0 st_next_result() - got CS_CMD_DONE: resetting ACTIVE, moreResults, dyn_execed, exec_done clear_sth_flags() - resetting ACTIVE, moreResults, dyn_execed, exec_done clear_sth_flags() - reset inUse flag - execute= -1 - $DBI::err= undef - $DBI::errstr= 'Server message number=5702 severity=10 state=1 line=2 server=dev_barbie01 text=ASE is terminating this process.' Notice that although errstr contains the error message, err is undef. This error happens when there is a stack trace on the server side (infected with 11, or similar) where ASE has to terminate the connection. It's an indication of a bug in ASE. The next time the connection was used it would fail with Message String: ct_send(): network packet layer: internal Client Library error: State error: trying to write when connection is expecting a read. I've appended a patch that seems to fix the problem, but I don't know if it's doing the right thing in the best way. For example, I tried adjusting the severity 10 to severity = 10 in the code below but that caused some tests to fail. Normal - there are other severity 10 errors that are not fatal or even errors as such. Actually I'm surprised that the 5702 error is only a 10, but I guess this will also be delivered when a DBA kills the connection from the server side (kill spid), and that might not be rated as a really serious issue. Michael, any chance you could review this and get it (or a better fix) released soonish? The fix looks reasonable, but I think what you are seeing might be an indication of a deeper problem when the connection is abruptly lost. Normally the connection should be marked dead in this condition, and DBD::Sybase should detect it. Michael -- Michael Peppler - Peppler Consulting SaRL [EMAIL PROTECTED] - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: Multiple selectrow_array calls with statement handle error
Douglas Wilson wrote:
With DBI 1.602 and DBD::Sybase 1.08 I get:
Can't locate object method DELETE via package DBI::st
on the second selectrow_array call.
If I replace $sth with $sql in the selectrow_array calls, then it
works correctly.
I did find a similar problem here:
http://www.nntp.perl.org/group/perl.dbi.users/2007/06/msg31486.html
but I thought that was fixed (did it get unfixed? :-)
I get the same error whether or not I have placeholders and bind parameters.
Here's the code:
use DBI;
my $dbh = DBI-connect(
'dbi:Sybase:server=SERVERNAME;database=dbname',
'user_name', 'password', {
RaiseError = 1,
});
my $sql = 'select some_column from my_table where my_id = ?';
my $sth = $dbh-prepare($sql);
my $id = 10600;
my $total;
( $total ) = $dbh-selectrow_array( $sth, undef, $id );
( $total ) = $dbh-selectrow_array( $sth, undef, $id );
I was able to reproduce it. I don't know yet if this is a DBD::Sybase
problem or something else. Unfortunately I don't have much time to debug
this.
Michael
--
Michael Peppler - Peppler Consulting SaRL
[EMAIL PROTECTED] - http://www.peppler.org
Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com
Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: DBD Sybase 1.08: Invalid lvalue in Sybase.xsi during MAKE
Joe Lushinski wrote: I'm trying to setup my Perl and DBI/DBD:Sybase development environment for the first time on Mac OS X (Tiger v10.4). I get errors running MAKE after the make Makefile.PL in DBD-Sybase-1.08 I installed XCode to get the C compilers, Make, etc. I installed Perl 5.8.6 I Installed Sybase OpenClient 12.5.1 ASE Edition and added the appropriate environment variables for Sybase. I can connect to my database using jSQL. I downloaded the DBI 1.602 module and did the make Makefile.PL , MAKE, make test, and make install (all went well) I downloaded DBD-Sybase-1.08 and did the make Makefile.PL , but when I try to run MAKE with the MAKEFILE that was generated, I get this error: cc -c -I/Applications/Sybase/System/OCS-12_5/include -I/Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DBI -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include -O3 -DVERSION=\1.08\ -DXS_VERSION=\1.08\ -I/System/Library/Perl/5.8.6/darwin-thread-multi-2level/CORE Sybase.cSybase.xsi: In function 'XS_DBD__Sybase__db_disconnect':Sybase.xsi:277: error: invalid lvalue in assignmentSybase.xsi: In function 'XS_DBD__Sybase__db_DESTROY':Sybase.xsi:336: error: invalid lvalue in assignmentmake: *** [Sybase.o] Error 1 I haven't tried the recent DBI versions yet, so I need to look into this, but it will take me a week or more (AFK next week). Michael -- Michael Peppler - Peppler Consulting SaRL [EMAIL PROTECTED] - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: perl on ncib1psrr002
Badrinath, Itta wrote: Hi , We downloaded DBD::Sybase 1.08 http://www.peppler.org/downloads/DBD-Sybase-1.08.tar.gz from peppler.org and ran the necessary Makefile on our Linux host. When we ran the program (depends_analyze.pl - GEMS Ed Barlow) we are getting the errors below. We are not sure if we are missing something. Can you help us? [EMAIL PROTECTED]:/home/a397179/gems/gem/ADMIN_SCRIPTS/bin perl depends_analyze.pl -S TIER2QA -Usa -Ppassword depends_analyze.pl : run at Thu Mar 27 13:02:46 2008 OUTPUT DIRECTORY=/home/a397179/gems/gem/data/depends Had to create DBD::Sybase::dr::imp_data_size unexpectedly at /usr/lib/perl5/site_perl/5.8.3/x86_64-linux-thread-multi/DBI.pm line 1211. Had to create DBD::Sybase::db::imp_data_size unexpectedly at /usr/lib/perl5/site_perl/5.8.3/x86_64-linux-thread-multi/DBI.pm line 1241. Undefined subroutine DBD::Sybase::db::_login called at /usr/lib/perl5/site_perl/5.8.3/x86_64-linux-thread-multi/DBD/Sybase.pm line 90. At first look it appears that DBD::Sybase isn't installed correctly. Did you get any errors during the install process? Did make test work correctly? Michael -- Michael Peppler - Peppler Consulting SaRL [EMAIL PROTECTED] - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: What should the contents of config.pl contain?
Davis, Reginald wrote: Help with the installation of Perl dbi for Sybase. I have downloaded the source module for Sybase: *DBD::Sybase http://search.cpan.org/author/MEWP/DBD-Sybase-1.08/Sybase.pm* Sybase database driver for the DBI module DBD-Sybase-1.08 http://search.cpan.org/~mewp/DBD-Sybase-1.08/ (5 Reviews http://cpanratings.perl.org/d/DBD-Sybase) - 21 Apr 2007 - Michael Peppler http://search.cpan.org/~mewp/ One of the files named: Makefile_PL has an include statement, which includes a file that does not exist Ie: require “./util/config.pl” I think you're mixing two different Makefile.PL files. The config.pl file is used by the Makefile.PL of sybperl-2.18, not by DBD::Sybase's Makefile.PL Michael -- Michael Peppler - Peppler Consulting SaRL [EMAIL PROTECTED] - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: Strange results returned using Linux to MS SQL 2005 through Sybase and FreeTDS
Thomas Möller wrote:
Hi all,
I'm new to the usage of the FreeTDS and DBD::Sybase combination.
I am seemingly able to connect to the DB correctly. It may perhaps
be as simple as my MSSQL syntax is failing? I have verified that
I am at all able to communicate correctly with the database by
using the tool tsql which work like a charm giving me the
expected results.
However, when executing the classical test PERL script to fetch
the server version:
if($sth-execute) {
@dat = $sth-fetchrow;
print @dat\n;
}
If that's the actual script you ran then the error is in the fetchrow()
call above. You do
$sth-fetchrow;
instead of
$sth-fetchrow;
As you don't have use strict, nor warnings, perl lets you do this
without complaining. In this case it interprets fetchrow as a string,
which evaluates to 0 in a numerical context ($sth - 0), which returns a
number.
Michael
--
Michael Peppler - Peppler Consulting SaRL
[EMAIL PROTECTED] - http://www.peppler.org
Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com
Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: DBD::Sybase context allocation routine failed
Peter Levine wrote: Hi, Is there a way to determine which libraries the DBI/DBD used when it was installed? This information is not in perl -V. There are several different SYBASE home directories on this server each with sub-directories for ASE or OCS versions. (I didn't install it -- I assume that this can be configured somehow in the makefile or otherwise when installing.) I am now getting a more specific error message when I set SYBASE to OCS. The dba says that this config file, 'objectid/dat', is used by ASE not OCS. Your DBA is wrong... :-) /The context allocation routine failed. The following problem caused the failure: Invalid context version. The context allocation routine failed when it tried to load localization files!! One or more following problems may caused the failure Your sybase home directory is /home/sybase/OCS-12_5. Check the environment variable SYBASE if it is not the one you want! Cannot access file /home/sybase/OCS-12_5/config/objectid.dat/ OK - so now the problem is that your SYBASE env variable points to /home/sybase/OCS-12_5. If that directory does include the Sybase libs then SYBASE should point to /home/sybase, so that it finds /home/sybase/config/objectid.dat. Michael -- Michael Peppler - Peppler Consulting SaRL [EMAIL PROTECTED] - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: DBD::Sybase context allocation routine failed
What this means is that the SYBASE env. variable points to the wrong directory when running the CGI script. This directory most likely has older Sybase OpenClient libraries, hence the invalid context error. Michael Peter Levine wrote: hi, I should add that i am running this as a cgi-bin script. And that i get the error whether or not I include a print header() statement. Also, I do not get the error if I run the script from the command line with the print header() statement. Pete - Original Message From: Tim Bunce [EMAIL PROTECTED] To: Alexander Foken [EMAIL PROTECTED] Cc: Peter Levine [EMAIL PROTECTED]; dbi-users@perl.org Sent: Wednesday, February 13, 2008 8:59:27 AM Subject: Re: DBD::Sybase context allocation routine failed True, but _very_ unlikely to be relevant to this problem. Tim. On Wed, Feb 13, 2008 at 04:04:23PM +0100, Alexander Foken wrote: You need the module, but you should not load it explicitly. DBI will take care of loading and initialising the module. Alexander On 13.02.2008 07:09, Peter Levine wrote: Hi, Hmmm. I thought I needed it. So are you saying that i can do all my SQL statments (just basic inserts, updates and selects) without he DBD module? I guess then I'm unclear on when I would need it. Pete - Original Message From: Jonathan Leffler [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: dbi-users@perl.org Sent: Tuesday, February 12, 2008 6:25:35 PM Subject: Re: DBD::Sybase context allocation routine failed On Feb 12, 2008 3:26 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: attempting a DB connection using a brand new installation of perl 5.8.8 on an old sun box: 'sun4u sparc SUNW,Ultra-4'. i have connectivity. this command line script returns a reference to a hash: perl -MDBI -e 'print DBI- connect(DBI:Sybase:server=,user,password)' but when i attempt to run this stub script: #!/usr/local/bin/perl5.8.8 use strict; use CGI qw(:standard); use DBI; use DBD::Sybase; I get this error: The context allocation routine failed. The following problem caused the failure: Invalid context version. Content-Type: text/html; charset=ISO-8859-1 I don't get the error it if I comment out the DBD::Sybase statement Any help is much appreciated. Why do you want to 'use DBD::Sybase' given that the working example shows that it is not necessary to do so? If you were importing some specific symbols from DBD::Sybase, it would make sense - but you aren't self-evidently doing that, so it doesn't make much sense. -- Alexander Foken mailto:[EMAIL PROTECTED] http://www.foken.de/alexander/ -- Michael Peppler - Peppler Consulting SaRL [EMAIL PROTECTED] - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: Sybase TEXT field updates..
[EMAIL PROTECTED] wrote: Hello all, So, I'm trying to do an insert into a two column table, with VARCHAR(40) key column and a TEXT column as the second field. The below code should work, but for some reason is not... I have some other code that does work, but it doesn't use placeholders. Is that the issue? The code that does work actually updates the same table I'm trying to update below. The problem is, with this set of data, I cannot guarantee that there will be no quotes, so I feel that I need to use placeholders... Yes - that's the issue. TEXT/IMAGE columns can't be used with placeholders, just as they can't be used as parameters to stored procedures. The DBD::Sybase docs discuss this, and the proprietary way of updating/inserting TEXT/MAGE data without embedding it in the SQL statements. Michael -- Michael Peppler - Peppler Consulting SaRL [EMAIL PROTECTED] - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: DBD::Sybase, serverType
In 1.08 the only check is for ASE - so if you pass in anything else then fetching @@version and a few other things will not be done. In the next release you can also pass in RA - for ReplicationAgent. This will also turn off all ct_options() calls. I needed this to be able to talk to the Sybase Rep Agent for Oracle. This is a java app that reads the oracle redo logs and sends the data to Sybase replication server. The app can't handle ct_options() calls, and actually kills the connection if you use them (not good :-) Michael Extranet [EMAIL PROTECTED] - 02.10.2007 21:07 To: dbi-users cc: Subject:DBD::Sybase, serverType From the docs: serverType Tell DBD::Sybase what the server type is. Defaults to ASE. Setting it to something else will prevent certain actions (such as setting options, fetching the ASE version via @@version, etc.) and avoid spurious errors. Where can we find a list of the other types aside from ASE? -- Matthew O. Persico This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: DBD::Sybase for ASE15.0.2?
I believe that there is a bat file that will either rename or add new copies of the libraries with the old names. However, as OpenClient has changed a bit I would not be 100% confident that the binary built for 12.5.x will work with OCS 15. Michael Extranet [EMAIL PROTECTED] - 11.09.2007 23:04 To: dbi-users cc: Subject:DBD::Sybase for ASE15.0.2? I'm trying to use DBD::Sybase 1.07.01 (from Michael's website) (+ActivePerl v5.8.8) with Sybase ASE15.0.2 on WinXP... When I use DBD::Sybase I get the following error: The application has failed to start because libct.dll was not found The only similar library I can find is libsybct.dll. Anyone have any ideas how to solve this, please? Thanks, Steve This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Do not print this message unless it is necessary, consider the environment. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. N'imprimez ce message que si necessaire, pensez a l'environnement.
Re: Number of row fields inconsistent with NUM_OF_FIELDS, NUM_OF_FIELDS updated
YOu need to upgrade your DBD::Sybase package - version 1.08 handles this correctly. Michael Extranet [EMAIL PROTECTED] - 29.08.2007 10:15 To: dbi-users cc: Subject:Number of row fields inconsistent with NUM_OF_FIELDS, NUM_OF_FIELDS updated I'm currently moving a perl script from an old Red Hat to a new Debian machine. The script connects to Microsoft SQL Server using FreeTDS. It runs fine on the new machine, but gives these warnings: DBD::Sybase::st fetchrow_hashref warning: Number of row fields inconsistent with NUM_OF_FIELDS, NUM_OF_FIELDS updated This message originates from the package libdbi-perl-1.53, file DBI.xs, function dbih_get_fbav. The new machine is running Debian 4.0, perl 5.8.8. If you have seen this error before or have a clue what it means, please share :) This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Do not print this message unless it is necessary, consider the environment. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. N'imprimez ce message que si necessaire, pensez a l'environnement.
Re: DBD::Sybase install issue
You should always specify if you are using Sybase or FreeTDS client software - I'm guessing the latter. You can work around the issue by adding a #define for CS_LOGIN_STATUS in dbdimp.c. Alternatively this may already have been solved in a more recent version of FreeTDS - you should probably check there. FWIW CS_LOGIN_STATUS should be defined to 9104... Michael Extranet [EMAIL PROTECTED] - 15.08.2007 15:43 To: dbi-users cc: Subject:DBD::Sybase install issue Im trying to install DBD::Sybase, Im getting past perl Makefile.PL - all looks normal. When I try to make I get the following output: cc -c -I/usr/local/include -DSYB_LP64 -DNO_BLK=1 -I/opt/perl/lib/site_perl/5.8.8/x86_64-linux/auto/DBI -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -DVERSION=\1.08\ -DXS_VERSION=\1.08\ -fpic -I/opt/perl/lib/5.8.8/x86_64-linux/CORE dbdimp.c dbdimp.c: In function `clientmsg_cb': dbdimp.c:328: error: `CS_LOGIN_STATUS' undeclared (first use in this function) dbdimp.c:328: error: (Each undeclared identifier is reported only once dbdimp.c:328: error: for each function it appears in.) make: *** [dbdimp.o] Error 1 uname -a Linux corp-alt-47 2.6.5-7.286-smp #1 SMP Thu May 31 10:12:58 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux perl -v This is perl, v5.8.8 built for x86_64-linux environmental var SYBASE is set to /usr/local Any help is appreciated Ted Fiedler -- If you mess with a thing long enough, it'll break. -- Schmidt This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Do not print this message unless it is necessary, consider the environment. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. N'imprimez ce message que si necessaire, pensez a l'environnement.
Re: Problem compiling DBD::Sybase with CentOS 4.5
Unfortunately in DBD::Sybase 1.08 I removed some code that allowed it to work with older DBI versions. DBD::Sybase 1.08 requires a fairly recent version of DBI (I haven't check the exact version). If you upgrade your DBI to the current version you should have no problems. Michael Extranet [EMAIL PROTECTED] - 23.07.2007 14:39 To: dbi-users cc: Subject:Problem compiling DBD::Sybase with CentOS 4.5 Hi. I am failing completely to get DBD::Sybase running, and annoyingly I can't see why! This is normally pretty painless. [EMAIL PROTECTED] DBD-Sybase-1.08]# make gcc -c -I/opt/sybase/OCS-12_5/include -I/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -m32 -march=i386 -mtune=pentium4 -DVERSION=\1.08\ -DXS_VERSION=\1.08\ -fPIC -I/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE Sybase.c In file included from Sybase.c:352: /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/Driver_xst.h: In function `dbixst_bounce_method': /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/Driver_xst.h:14: error: `my_perl' undeclared (first use in this function) /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/Driver_xst.h:14: error: (Each undeclared identifier is reported only once /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/Driver_xst.h:14: error: for each function it appears in.) /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/Driver_xst.h: In function `dbdxst_bind_params': /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/Driver_xst.h:54: error: `my_perl' undeclared (first use in this function) /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/Driver_xst.h: In function `dbdxst_fetchall_arrayref': /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI/Driver_xst.h:75: error: `my_perl' undeclared (first use in this function) make: *** [Sybase.o] Error 1 # rpm -qa libdbi* libdbi-0.6.5-10.RHEL4.1 libdbi-devel-0.6.5-10.RHEL4.1 # echo $LANG C # echo $SYBASE /opt/sybase Sybase 12.5.3/EBF 13332 ESD#7. Can anyone suggest anything? This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Do not print this message unless it is necessary, consider the environment. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. N'imprimez ce message que si necessaire, pensez a l'environnement.
Re: Error installing DBD::Sybase on Solaris
First questions first... Do you have a Sybase client installed ? If so, make sure that your SYBASE env. variable points at the Sybase root directory, and make sure that you have sourced the SYBASE.sh file that is found in that directory. Once that is done you should have it a lot easier. Michael Extranet [EMAIL PROTECTED] - 09.05.2007 16:40 To: dbi-users cc: Subject:Error installing DBD::Sybase on Solaris Hi, I am not able to install the DBD::Sybase module on solaris 5.8. Even ppd packages are not getting installed(I am difficulty in finding one)Can please somebody help The error is: bash-2.03# perl Makefile.PL Can't find the Client Library include files under /opt/netcool/omnibus/platform/solaris2 at Makefile.PL line 134, IN line 44. I am also having problem installing Sybase Client Library API ie. sybperl-2.18 http://search.cpan.org/~mewp/sybperl-2.18/. The details of perl is given below: bash-2.03# perl -V Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration: Platform: osname=solaris, osvers=2.6, archname=sun4-solaris-thread-multi uname='sunos axe 5.6 generic_105181-33 sun4u sparc sunw,ultra-60 ' config_args='-des -Dcc=gcc -Dcf_by=ActiveState [EMAIL PROTECTED] -Ud_sigsetjmp -Dusethreads -Duseithreads -Ulocincpth= -Uloclibpth= -Accflags=-DNO_HASH_SEED -Dprefix=/opt/ActivePerl-5.8-Dinc_version_list= 5.8.0/$archname 5.8.0 -Duselargefiles' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DNO_HASH_SEED -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O', cppflags='-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DNO_HASH_SEED -fno-strict-aliasing' ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers=' solaris2.6' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc', ldflags =' ' libpth=/usr/lib /usr/ccs/lib /usr/local/lib libs=-lsocket -lnsl -ldl -lm -lpthread -lc perllibs=-lsocket -lnsl -ldl -lm -lpthread -lc libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-fPIC', lddlflags='-G' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: ActivePerl Build 807 Built under solaris Compiled at Nov 3 2003 19:29:55 %ENV: PERL5LIB=/opt/ActivePerl-5.8/lib/5.8.1/sun4-solaris-thread-multi @INC: /opt/ActivePerl-5.8/lib/5.8.1/sun4-solaris-thread-multi /opt/ActivePerl-5.8/lib/5.8.1/sun4-solaris-thread-multi /opt/ActivePerl-5.8/lib/5.8.1 /opt/ActivePerl-5.8/lib/site_perl/5.8.1/sun4-solaris-thread-multi /opt/ActivePerl-5.8/lib/site_perl/5.8.1 /opt/ActivePerl-5.8/lib/site_perl Regards, Amith This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
RE: temporary table disapears
You should run this with DBI-trace() turned on to see what DBD::ODBC
actually does. The temp tables should only be dropped when the connection
is closed.
Michael
Extranet
[EMAIL PROTECTED] - 11.05.2007 00:19
To: martin.evans, dbi-users
cc:
Subject:RE: temporary table disapears
Martin, Autocommit off doesn't help local temps persist after the
execute.
Andon said that batching all the commands in the same execute is not an
option for him, so the only working alternative so far is to consider
global temps (##foo). They do persist after an execute and throughout
an entire session.
Consider these examples:
my $s1 = 'create table #foo (a int not null)';
my $s2 = 'insert into #foo values (1)';
my $s3 = 'select * from #foo';
$dbh-{AutoCommit} = 0;# trying to see if this help, but it
doesn't
my $sth;
$sth = $dbh-prepare($s1);
$sth-execute(); # works: table created
$sth = $dbh-prepare($s1);
$sth-execute(); # works: can recreate table because
original is gone
$sth = $dbh-prepare($s2);
$sth-execute(); # doesn't work: table is gone
$sth = $dbh-prepare($s3);
$sth-execute(); # doesn't work: table is gone
$sth = $dbh-prepare($s1; $s2; $s3);
$sth-execute(); # works: table exists across batched
commands
-Original Message-
From: Martin Evans [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 10, 2007 7:39 AM
To: dbi-users@perl.org
Subject: Re: temporary table disapears
CAMPBELL, BRIAN D (BRIAN) wrote:
You're right. It's the the other way around from what I said.
However, when I tested this yesterday it seemed I was getting an error
on the create command also. But I re-examined the results more
carefully today and the create worked OK; it was just the insert that
failed. However they were both run on the same connection (same $dbh
handle). So it seems that local temps don't persist after an
execute() call, as Andon supposed.
What if you turn autocommit off - do the temporary tables exist for
longer then?
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 10:49 PM
To: CAMPBELL, BRIAN D (BRIAN)
Cc: [EMAIL PROTECTED]; dbi-users@perl.org
Subject: RE: temporary table disapears
I'm pretty sure that #tmp is a local temporary table, and ##tmp
is a
global temporary table...
So the original problem is most likely that the create table
#tmp and
the insert into #tmp statements aren't being run on the same physical
connection. I don't know DBD::ODBC, but I can tell you that
DBD::Sybase could possibly have opened a second connection under the
covers if it thought the first statement hadn't been completely
processed yet.
Michael
Extranet
[EMAIL PROTECTED] - 09.05.2007 18:40
To:atschauschev, dbi-users
cc:
Subject:RE: temporary table disapears
Actually I tried this against SQL 2000, DBI 1.53 and DBD::ODBC
1.13...
You should be getting 2 errors, the same error from both
prepares.
In
other words, #foo isn't being treated as a proper table name.
Naturally, these statements work fine if you just use foo (which
isn't
temp).
However, #foo should represent a global temp table, and this
is not
being accepted as a valid name. Not sure why.
But ##foo works fine, and the table does persist across executes
while
the $dbh connection is open. With 2 #'s, it's a local temp
table
which means it's not visible to other sessions. If that's OK,
perhaps
you can use that instead.
-Original Message-
From: Andon Tschauschev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 8:31 AM
To: dbi-users@perl.org
Subject: temporary table disapears
Hello,
I am using DBI 1.51 and DBD::ODBC 1.13, connecting to MSSQL2005.
Executing following statements:
$sth = $dbh-prepare('create table #foo (a int not null)');
$sth-execute(); $sth = $dbh-prepare('insert into #foo values
(1)');
$sth-execute();
generate an error:
[Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object
name
'#foo'.
So, the temporary table disapears (I tested it on Sybase,
using
DBD::Sybase, too, there is no an error). Since the two
statements are
dynamically created (between come other statements), I cannot
execute
in
one batch $sth = $dbh-prepare('create table #foo (a int not
null)
insert into #foo values (1)); $sth-execute();
at once...
How can I avoid this problem?
Regards!
Andon
-
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
This message and any
RE: temporary table disapears
I'm pretty sure that #tmp is a local temporary table, and ##tmp is a
global temporary table...
So the original problem is most likely that the create table #tmp and the
insert into #tmp statements aren't being run on the same physical
connection. I don't know DBD::ODBC, but I can tell you that DBD::Sybase
could possibly have opened a second connection under the covers if it
thought the first statement hadn't been completely processed yet.
Michael
Extranet
[EMAIL PROTECTED] - 09.05.2007 18:40
To: atschauschev, dbi-users
cc:
Subject:RE: temporary table disapears
Actually I tried this against SQL 2000, DBI 1.53 and DBD::ODBC 1.13...
You should be getting 2 errors, the same error from both prepares. In
other words, #foo isn't being treated as a proper table name.
Naturally, these statements work fine if you just use foo (which isn't
temp).
However, #foo should represent a global temp table, and this is not
being accepted as a valid name. Not sure why.
But ##foo works fine, and the table does persist across executes while
the $dbh connection is open. With 2 #'s, it's a local temp table
which means it's not visible to other sessions. If that's OK, perhaps
you can use that instead.
-Original Message-
From: Andon Tschauschev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 09, 2007 8:31 AM
To: dbi-users@perl.org
Subject: temporary table disapears
Hello,
I am using DBI 1.51 and DBD::ODBC 1.13, connecting to MSSQL2005.
Executing following statements:
$sth = $dbh-prepare('create table #foo (a int not null)');
$sth-execute(); $sth = $dbh-prepare('insert into #foo values (1)');
$sth-execute();
generate an error:
[Microsoft][ODBC SQL Server Driver][SQL Server]Invalid object name
'#foo'.
So, the temporary table disapears (I tested it on Sybase, using
DBD::Sybase, too, there is no an error). Since the two statements are
dynamically created (between come other statements), I cannot execute in
one batch $sth = $dbh-prepare('create table #foo (a int not null)
insert into #foo values (1)); $sth-execute();
at once...
How can I avoid this problem?
Regards!
Andon
-
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
-
Ce message et toutes les pieces jointes (ci-apres le
message) sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
Re: DBD::Sybase
I presume that you are on a 64bit version of Linux. If that's the case, then you have two choices: 1. Rebuild perl (and all the other XS extensions that you use) in 32bit mode or 2. Find 64 bit libraries for Sybase. These exist, but are not free. You should be able to buy a developer edition of ASE for linux x86-64 from eshop.sybase.com for about US$250 or so. Michael Extranet [EMAIL PROTECTED] - 28.04.2007 02:27 To: dbi-users cc: Subject:DBD::Sybase Hi, I am trying to install DBD::Sybase through CPAN, and I seem to be running into trouble with linking 32/64 bit code by the looks of it. I was using the libraries included with Sybase ASE 15 express edition, available on sybase's web site. Does anyone know what should be done here? Thanks, Running Mkbootstrap for DBD::Sybase () chmod 644 Sybase.bs rm -f blib/arch/auto/DBD/Sybase/Sybase.so gcc -L/opt/sybase/OCS-15_0/lib -shared Sybase.o dbdimp.o -o blib/arch/auto/DBD/Sybase/Sybase.so -L/opt/sybase/OCS-15_0/lib -lsybct -lsybcs -lsybtcl -lsybcomn -lsybintl -lsybblk -ldl -lm /usr/bin/ld: skipping incompatible /opt/sybase/OCS-15_0/lib/libsybct.so when searching for -lsybct /usr/bin/ld: skipping incompatible /opt/sybase/OCS-15_0/lib/libsybct.a when searching for -lsybct /usr/bin/ld: skipping incompatible /opt/sybase/OCS-15_0/lib/libsybct.so when searching for -lsybct /usr/bin/ld: skipping incompatible /opt/sybase/OCS-15_0/lib/libsybct.a when searching for -lsybct /usr/bin/ld: cannot find -lsybct collect2: ld returned 1 exit status make: *** [blib/arch/auto/DBD/Sybase/Sybase.so] Error 1 MEWP/DBD-Sybase-1.08.tar.gz /usr/bin/make -- NOT OK This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
ANNOUNCE: DBD::Sybase 1.08
I've just released DBD::Sybase 1.08 to CPAN. This a bug fix and performance enhancement release. I'd like to thank Tim Bunce for his help with this release. From the CHANGES file: Release 1.08 Detect missing libblk.a library, and disable the BLK api calls if necessary. Added code to force dlopen() to use RTLD_GLOBAL. Corrected ct_option() functionality detection. Fixed incorrect handling of bind_params() (Thanks to Tim Bunce). Added serverType DSN parameter. Added tds_keepalive DSN parameter. Fixed incorrect handling of multiple result sets with DBI 1.53 and later. Re-wrote $dbh-ping() in C, it's now four times faster. Allow automated build without prompts. Improved nsql(). Added corrected handling of DATE and TIME values (ASE 12.5.2 and later). Added handling of UNSIGNED INT and BIGINT (ASE 15 and later). Added PERL_NO_GET_CONTEXT #define. Bug Fixes 624 - Empty strings incorrectly passed as NULL. 616 - Spurious error message when the login request times out. 614 - Documentation improvement for syb_xxx methods. 610 - Segfault when using signals with the threaded libraries and perl = 5.8. As always, bug fixes, comments, etc. are welcome! Michael -- Michael Peppler - Peppler Consulting SaRL [EMAIL PROTECTED] - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: DBD::Sybase 1.07_06
Matthew Persico wrote: On 4/10/07, Michael Peppler [EMAIL PROTECTED] wrote: All, I'm finally getting closer to releasing the DBD::Sybase 1.08, which will have a number of fixes. I would like to encourage those of you who have the time and the resources to please download and install version 1.07_06 from http://www.peppler.org/downloads and let me know of any issues that you may find. From the CHANGES file: Detect missing libblk.a library, and disable the BLK api calls if necessary. Added code to force dlopen() to use RTLD_GLOBAL. Corrected ct_option() functionality detection. Fixed incorrect handling of bind_params() (Thanks to Tim Bunce). Added serverType DSN parameter. The exact details escape me, but do you recall a problem at one point connecting to either a replication or an IQ server because the DBD::Sybase code tries to query a table that does not exist in such a server? Is that what the serverType DSN param is supposed to help with? Yes, and also to allow (future versions of) DBD::Sybase to turn off certain features when they aren't available. Michael -- Michael Peppler - Peppler Consulting SaRL [EMAIL PROTECTED] - http://www.peppler.org Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com Sybase on Linux FAQ - http://www.peppler.org/FAQ/linux.html
Re: DBD::Sybase compilation
You used the 32bit libraries with a 64bit version of perl - this will NOT work. You either need to install a 64bit version of the Sybase client (SDK), or install a 32bit version of perl. Michael Extranet [EMAIL PROTECTED]@sea.gmane.org - 20.03.2007 17:42 Sent by:[EMAIL PROTECTED] To: dbi-users cc: Subject:DBD::Sybase compilation Hello, We would like to install DBD::Sybase on Solaris 2.9. We have perl 5.6.1 coming with the system, with DBI 1.54 installed. Our Sybase OpenClient is 12.5.3 (32bits). A lot of similar errors occur when running make test : PERL_DL_NONLAZY=1 /bin/perl -Iblib/arch -Iblib/lib -I/usr/perl5/5.6.1/lib/sun4-solaris-64int -I/usr/perl5/5.6.1/lib -e 'use Test::Harness qw(runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t t/autocommitNOK 2/9 # Failed test 'use DBD::Sybase;' # at t/autocommit.t line 18. # Tried to use 'DBD::Sybase'. # Error: Can't load 'blib/arch/auto/DBD/Sybase/Sybase.so' for module DBD::Sybase: ld.so.1: perl: fatal: relocation error: file blib/arch/auto/DBD/Sybase/Sybase.so: symbol comn_malloc: referenced symbol not found at /usr/perl5/5.6.1 /lib/sun4-solaris-64int/DynaLoader.pm line 206. # Compilation failed in require at (eval 9) line 2. # BEGIN failed--compilation aborted at t/autocommit.t line 18. Had to create DBD::Sybase::dr::imp_data_size unexpectedly at /usr/perl5/site_perl/5.6.1/sun4-solaris-64int/DBI.pm line 1195. Use of uninitialized value in subroutine entry at /usr/perl5/site_perl/5.6.1/sun4-solaris-64int/DBI.pm line 1195. Had to create DBD::Sybase::db::imp_data_size unexpectedly at /usr/perl5/site_perl/5.6.1/sun4-solaris-64int/DBI.pm line 1195. Use of uninitialized value in subroutine entry at /usr/perl5/site_perl/5.6.1/sun4-solaris-64int/DBI.pm line 1195. Undefined subroutine DBD::Sybase::db::_login called at blib/lib/DBD/Sybase.pm line 94. # Looks like you planned 9 tests but only ran 2. # Looks like you failed 1 test of 2 run. # Looks like your test died just after 2. t/autocommitdubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 2-9 Failed 8/9 tests, 11.11% okay We don't know if using a recent version of perl would help ? We had no problem to install this module on Linux with perl 5.8.0. or -- This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: Error installing DBD::Sybase RPM
I'm not sure about the first error (x86_64-pld-...), though I suspect that this is a particular build of perl. The second is simpler - you don't have libct.so installed (the Sybase Client Library lib). In this case I suspect that the RPM expects to have the FreeTDS version of Client Library installed, as opposed to the Sybase version. So you need to install freetds first, at the very least (see http://www.freetds.org). Michael Extranet [EMAIL PROTECTED] - 15.12.2006 08:01 To: dbi-users cc: Subject:Error installing DBD::Sybase RPM Can anyone help me with this error? # rpm -Uhv perl-DBD-Sybase-1.07-1.x86_64.rpm error: Failed dependencies: /usr/lib64/perl5/vendor_perl/5.8.0/x86_64-pld-linux-thread-multi is needed by perl-DBD-Sybase-1.07-1.x86_64 libct.so.3()(64bit) is needed by perl-DBD-Sybase-1.07-1.x86_64 rpmlib(PayloadIsLzma) = 4.4.6-1 is needed by perl-DBD-Sybase-1.07-1.x86_64 Thanks in advance This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: Fwd: Can't connect to Sybase Rep server
Hi Matthew,
The real problem is that there is no way to detect that we're trying to
connect to a rep server, so DBD::Sybase still tries to use teh ct_option()
calls, and to get the version of the server (via select @@version).
Obviously these errors aren't real errors - so I guess there are two
possible solutions.
1 - on your end, check for error 2056 and if so ignore the content of
errstr:
$dbh = DBI-connect();
if($dbh-err $dbh-err != 2056) {
print $dbh-errstr;
}
It's obviously not a clean solution, but it should work.
2 - we add a new connection attribute that tells DBD::Sybase to not call
ct_option, and to not try to get the version. Maybe something like
$dbh = DBI-connect('dbi:Sybase:server=MSTR_REP;serverType=OS;...', 'sa',
'...', ...);
where OS means OpenServer. This could then be useful when connecting to
other types of openserver apps, not just RepServer.
I'm of course open to other suggestions as well.
Michael
Extranet
[EMAIL PROTECTED] - 23.11.2006 04:20
To: dbi-users
cc:
Subject:Fwd: Can't connect to Sybase Rep server
-- Forwarded message --
From: Matthew Persico [EMAIL PROTECTED]
Date: Nov 20, 2006 12:45 PM
Subject: Re: Can't connect to Sybase Rep server
To: Michael Peppler [EMAIL PROTECTED]
Well, it's been more than a week. :-) No, I have not been on jury duty
THAT long, but now this is a production problem...
Well not really, I was able to fall back to using DBD::Sybase 1.00.
On DBD::Sybase 1.07 and your test 1.07_02 (from March 6), I get an
error connecting to a rep server.
Here is a test piece of code:
use DBD::Sybase;
$ldbh = DBI-connect(dbi:Sybase:
.. server=REPP
.. ;hostname= . 'nycux-25k102'
,'REPP_maint'
,'***'
,{RaiseError=1});
print $ldbh-errstr();
my $dummy = 6;
and results:
Server message number=17001 severity=10 state=0 line=0 server=REPP
text=No SRV_OPTION handler installed.OpenClient message: LAYER = (1)
ORIGIN = (1) SEVERITY = (1) NUMBER = (183)
Server REPP, database
Message String: ct_options(): user api layer: external error: An error
was returned from the server while setting the options, check the
server message for details.
Server message number=2056 severity=12 state=0 line=0 server=REPP
text=Line 1, character 8: Incorrect syntax with 'select'.
Any suggestions?
On 3/6/06, Matthew Persico [EMAIL PROTECTED] wrote:
I'm on jury duty. It may take a week to get back to you.
On 3/6/06, Michael Peppler [EMAIL PROTECTED] wrote:
On Thu, 2006-03-02 at 13:53 -0500, Matthew Persico wrote:
See the four attachments. RS is rep server version, the others
should
be self explanitory. I included the .pl I used just for kicks.
Thanks
Hi Matthew,
Could you try the attached and see if it improves things for you?
Thanks,
Michael
--
Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com/
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
--
Matthew O. Persico
--
Matthew O. Persico
--
Matthew O. Persico
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
-
Ce message et toutes les pieces jointes (ci-apres le
message) sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
Re: Safely timing out DBI queries
And some drivers have a timeout parameter that handles this issue at the vendor API level (e.g. DBD::Sybase's timeout parameter that is handled internally by OpenClient). Michael Extranet [EMAIL PROTECTED] - 19.09.2006 15:37 To: henri cc: tyler, darnold, Tim.Bunce, dbi-users, dbi-dev Subject:Re: Safely timing out DBI queries I realize that this is very specific to the database, however, it may be possible to set a resource limit at the database level that will prevent the queries from consuming too much time. Chuck [EMAIL PROTECTED] wrote: On Sep 18, 2006, at 6:18 PM, Tyler MacDonald wrote: Dean Arnold [EMAIL PROTECTED] wrote: Which brings me back to the notion of non-blocking requests. Assuming many/most client libs do support an async capability, and a OOB cancel, then it should be possible to standardize the behavior externally. Attempting to standardize, let alone implement, non-blocking requests for the current DBI is a far bigger task than the above. On the other hand, I'd be *delighted* if you, or anyone else, would like to champion the work. cheap hack Start up a thread to handle the request, which sets a state variable on the statement handle then the request has been processed? /cheap hack The problem is not to know when a request is done processing. The problem is killing requests that are processing for too long. If you want kill them safely, you may not be able to kill them until they're done, which defeats the purpose. If you kill them unsafely, then the Perl interpreter might be in a dirty state, forcing you to thoroughly dispose of it if you want to be 100% safe. To kill the requests safely and when you want to, you need asynchronous support from the database client APIs and drivers, and quite a bit of standardized support code from DBI. H This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: trouble loading DBD sybase, 1_07_01
You are trying to link 32bit code with 64bit code. You either need to get the 64bit version of the Sybase client libraries, or rebuild perl in 32bit mode. Michael Extranet [EMAIL PROTECTED] - 09/09/2006 00:48 To:dbi-users cc: Subject:trouble loading DBD sybase, 1_07_01 Hi, I am trying to load DBD sybase on linux I am using RedHat 4, update 4 for x64_68 platform on an EM_64T machine. My updates are current. I am tying to load DBDSybase 1_07_01 (1_07 didn't work either) I am running a 32 bit version of sybase. I tried loading a 64 version of the middleware..this just created different errors. Here is the terminal output of pearl Makefile.pl and make.. [EMAIL PROTECTED] DBD_install]$ cd DBD-Sybase-1.07_01 [EMAIL PROTECTED] DBD-Sybase-1.07_01]$ ls BUGS dbdimp.hMakefile.PL README Sybase.pm CHANGES dbd-sybase.pod MANIFEST README.freetds Sybase.xs CONFIGdbivport.h META.yml README.vms t dbdimp.c eg PWD.factory Sybase.h [EMAIL PROTECTED] DBD-Sybase-1.07_01]$ perl Makefile.PL Sybase OpenClient 15.0 found. By default DBD::Sybase 1.05 and later use the 'CHAINED' mode (where available) when 'AutoCommit' is turned off. Versions 1.04 and older instead managed the transactions explicitly with a 'BEGIN TRAN' before the first DML statement. Using the 'CHAINED' mode is preferable as it is the way that Sybase implements AutoCommit handling for both its ODBC and JDBC drivers. Use 'CHAINED' mode by default (Y/N) [Y]: N Running in threaded mode - looking for _r libraries... Found -lsybct_r for -lsybct Found -lsybcs_r for -lsybcs Found -lsybtcl_r for -lsybtcl Found -lsybcomn_r for -lsybcomn Found -lsybintl_r for -lsybintl Found -lsybblk_r for -lsybblk Running in 64bit mode - looking for '64' libraries... BLK api available - found: sybblk_r The DBD::Sybase module need access to a Sybase server to run the tests. To clear an entry please enter 'undef' Sybase server to use (default: SYBASE): User ID to log in to Sybase (default: sa): Password (default: undef): x Sybase database to use on sa (default: undef): x * Writing login information, including password, to file PWD. Checking if your kit is complete... Looks good Multiple copies of Driver.xst found in: /usr/lib64/perl5/site_perl/5.8.5/x86_64- linux-thread-multi/auto/DBI/ /usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thr ead-multi/auto/DBI/ at Makefile.PL line 59 Using DBI 1.50 (for perl 5.008005 on x86_64-linux-thread-multi) installed in /us r/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/auto/DBI/ Writing Makefile for DBD::Sybase [EMAIL PROTECTED] DBD-Sybase-1.07_01]$ make cp dbd-sybase.pod blib/lib/DBD/dbd-sybase.pod cp Sybase.pm blib/lib/DBD/Sybase.pm /usr/bin/perl -p -e s/~DRIVER~/Sybase/g /usr/lib64/perl5/site_perl/5.8.5/x86_6 4-linux-thread-multi/auto/DBI//Driver.xst Sybase.xsi /usr/bin/perl /usr/lib/perl5/5.8.5/ExtUtils/xsubpp -typemap /usr/lib/perl5/5.8. 5/ExtUtils/typemap Sybase.xs Sybase.xsc mv Sybase.xsc Sybase.c gcc -c -I/opt/sybase_15_0_1/OCS-15_0/include -DNO_CHAINED_TRAN=1 -DSYB_LP64 -I/ usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LAR GEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -m64 -DV ERSION=\1.07_01\ -DXS_VERSION=\1.07_01\ -fPIC -I/usr/lib64/perl5/5.8.5/x86_ 64-linux-thread-multi/CORE Sybase.c gcc -c -I/opt/sybase_15_0_1/OCS-15_0/include -DNO_CHAINED_TRAN=1 -DSYB_LP64 -I/ usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi/auto/DBI -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LAR GEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -m64 -DV ERSION=\1.07_01\ -DXS_VERSION=\1.07_01\ -fPIC -I/usr/lib64/perl5/5.8.5/x86_ 64-linux-thread-multi/CORE dbdimp.c dbdimp.c: In function `_dbd_rebind_ph': dbdimp.c:4807: warning: passing arg 2 of `to_binary' from incompatible pointer t ype Running Mkbootstrap for DBD::Sybase () chmod 644 Sybase.bs rm -f blib/arch/auto/DBD/Sybase/Sybase.so gcc -L/opt/sybase_15_0_1/OCS-15_0/lib -shared Sybase.o dbdimp.o -o blib/arch/a uto/DBD/Sybase/Sybase.so -L/opt/sybase_15_0_1/OCS-15_0/lib -lsybct_r -lsybcs_r -lsybtcl_r -lsybcomn_r -lsybintl_r -lsybblk_r -ldl -lm /usr/bin/ld: skipping incompatible /opt/sybase_15_0_1/OCS-15_0/lib/libsybct_r.so when searching for -lsybct_r /usr/bin/ld: skipping incompatible /opt/sybase_15_0_1/OCS-15_0/lib/libsybct_r.a when searching for -lsybct_r /usr/bin/ld: skipping incompatible /opt/sybase_15_0_1/OCS-15_0/lib/libsybct_r.so when searching for -lsybct_r /usr/bin/ld: skipping incompatible /opt/sybase_15_0_1/OCS-15_0/lib/libsybct_r.a when searching for -lsybct_r /usr/bin/ld: cannot find -lsybct_r collect2: ld returned 1 exit status make: *** [blib/arch/auto/DBD/Sybase/Sybase.so] Error 1 Any Ideas?? This message and any attachments (the message) is intended
Re: finishing sth using Childhandles
Here's a little test:
#!/usr/bin/perl
use DBI;
my $dbh = DBI-connect('dbi:Sybase:server=DBA_SQL', '...', '...');
my $sth = $dbh-prepare(select * from histo..table_size where serverName =
'BPSREC5_SQL');
$sth-execute;
DBI-trace(5);
undef $dbh;
This produces the following:
DBI 1.51-ithread default trace level set to 0x0/5 (pid 22393)
Note: perl is running without the recommended perl -w option
DESTROY(DBI::st=HASH(0x9d98514)) ignored for outer handle (inner
DBI::st=HASH(0x9d984fc) has ref cnt 1)
- DESTROY for DBD::Sybase::st (DBI::st=HASH(0x9d984fc)~INNER)
thr#9bdc008
syb_st_finish() - ct_cancel(CS_CANCEL_ALL)
clear_sth_flags() - resetting ACTIVE, moreResults, dyn_execed,
exec_done
clear_sth_flags() - reset inUse flag
syb_st_destroy: called on 9d9abb8...
syb_st_destroy(): freeing imp_sth-statement
ct_cmd_drop() - CS_COMMAND 9d9aa28
syb_st_destroy(): cmd dropped: 1
- DESTROY= undef
dbih_clearcom 0x9d984fc (com 0x9d9abb8, type 3) done.
DESTROY(DBI::db=HASH(0x9d95b94)) ignored for outer handle (inner
DBI::db=HASH(0x9d96c18) has ref cnt 1)
- DESTROY for DBD::Sybase::db (DBI::db=HASH(0x9d96c18)~INNER)
thr#9bdc008
syb_db_disconnect() - ct_close()
- DESTROY= undef
dbih_clearcom 0x9d96c18 (com 0x9d97838, type 2) done.
-- DBI::END
- disconnect_all for DBD::Sybase::dr
(DBI::dr=HASH(0x9ceb734)~0x9d95ba0) thr#9bdc008
- disconnect_all= 1 at /usr/lib/perl5/site_perl/5.8.6
/i386-linux-thread-multi/DBI.pm line 698 via /home/pepm01a/tmp/child.pl
line 0
! - DESTROY in DBD::_::common for DBD::Sybase::dr
(DBI::dr=HASH(0x9d95ba0)~INNER) thr#9bdc008
! - DESTROY= undef during global destruction
dbih_clearcom 0x9ceb734 (com 0x9cd1dd8, type 1) done.
!DESTROY for DBI::dr=HASH(0x9ceb734) ignored (inner handle gone)
As you see this calls the DESTROY for the sth (which cancels the query),
and then calls the DESTROY for the dbh (which closes the connection). There
is no special code in DBD::Sybase to handle this case AFAIK.
Michael
Extranet
[EMAIL PROTECTED] - 29/08/2006 13:44
To:dbi-users
cc:
Subject:Re: finishing sth using Childhandles
Thanks, Tim.
One more question to the group:
If I undef $dbh when it is active and it has active (or inactive)
child handles, what happens exactly?
Is an actual $dbh-disconnect() made, and are the $sth's finished at
all? Is it DBD dependent?
Thanks in advance,
Henri.
On Aug 28, 2006, at 11:15 PM, Tim Bunce wrote:
On Thu, Aug 24, 2006 at 09:47:56AM +0200, Henri Asseily wrote:
Is the below the correct usage for finishing still active child
handles of a dbh?
foreach my $childh (@{$dbh-{ChildHandles}}) {
$childh-finish() if ($childh-{Type} eq 'st');
}
The children of a dbh will always be sth, but the test is harmless.
I'm getting an error when running the above code:
dbih_setup_fbav: invalid number of fields: -1, NUM_OF_FIELDS
attribute probably not set right
Looks like a bug (in the driver, I'd guess, but you don't say which)
because calling finish should never need to call dbih_setup_fbav.
But checking for Active will probably avoid the problem:
$_-finish for grep { $_-{Active} } @{$dbh-{ChildHandles}};
Tim.
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
-
Ce message et toutes les pieces jointes (ci-apres le
message) sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
Re: finishing sth using Childhandles
Ah! I think I know what happens... You probably have the syb_flush_finish attribute turned on - which means that DBD::Sybase will try to fetch all the results that are pending for the active sth. I'm going to have to look at the code to see how that could be invalidated (or fixed!) Michael Extranet [EMAIL PROTECTED] - 29/08/2006 15:56 To:dbi-users cc: Subject:Re: finishing sth using Childhandles On Aug 29, 2006, at 2:08 PM, [EMAIL PROTECTED] wrote: As you see this calls the DESTROY for the sth (which cancels the query), and then calls the DESTROY for the dbh (which closes the connection). There is no special code in DBD::Sybase to handle this case AFAIK. Thanks, I didn't have easy access to a DBI-enabled machine today :-) However, the dbh undef calls the sth DESTROY which calls the sth finish(), and the sth finish can, in some cases, throw an error such as the one I had that says : dbih_setup_fbav: invalid number of fields: -1, NUM_OF_FIELDS attribute probably not set right The in some cases above is after a signal interrupt, when the sth is potentially a bad state. So how do I clear the sth when I know it's in a bad state, without calling finish() that expects the sth to be in a workable state? H This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: max datatypes support of SQL Server 2005 for DBD-ODBC
DBD::Sybase will support whatever the underlying client libs are capable of handling. Michael Extranet [EMAIL PROTECTED] - 21/08/2006 15:27 To:fumiakiy cc:dbi-users Subject:Re: max datatypes support of SQL Server 2005 for DBD-ODBC Fumiaki Yoshimatsu wrote: I had a need to support [n]varchar(max) and varbinary(max) datatypes of MS SQL Server 2005, and patched DBD-ODBC. Below is the diff from the current svn. Does anyone know what, if any, support for these DBD::Sybase has? -- Steve Sapovits [EMAIL PROTECTED] This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: max datatypes support of SQL Server 2005 for DBD-ODBC
There is no configuration that can be done at the DBD::Sybase level for the BLK handling - if you are limited to 255 chars then it is most likely a limitation of the BLK api implementation of FreeTDS. Michael Extranet [EMAIL PROTECTED] - 21/08/2006 15:39 To:Michael PEPPLER cc:fumiakiy, dbi-users Subject:Re: max datatypes support of SQL Server 2005 for DBD-ODBC [EMAIL PROTECTED] wrote: DBD::Sybase will support whatever the underlying client libs are capable of handling. I'll throw the wrench in now: I'm using the DBD::Sybase bulk copy interface as well. That's working great but I'm getting a failure on a table that has a varchar(max) column. I haven't isolated it to that yet -- I'm going to test with and without that. In the meantime, if you have any knowledge to bestow on me regarding varchar(max) and bulk copies, let me know. This is a RH Linux environment, FreeTDS drivers. Perl 5.8.7, DBD::Sybase 1.07. Target database is MS SQL Server 9.0.2047. Bulk loading rocks by the way Michael. ;-) Michael Extranet [EMAIL PROTECTED] - 21/08/2006 15:27 To:fumiakiy cc:dbi-users Subject:Re: max datatypes support of SQL Server 2005 for DBD-ODBC Fumiaki Yoshimatsu wrote: I had a need to support [n]varchar(max) and varbinary(max) datatypes of MS SQL Server 2005, and patched DBD-ODBC. Below is the diff from the current svn. Does anyone know what, if any, support for these DBD::Sybase has? -- Steve Sapovits [EMAIL PROTECTED] This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. -- Steve Sapovits [EMAIL PROTECTED]
RE: Problem with DBI
Hi, I have no knowledge of the DBIx::ContextualFetch module, and so have no idea whether upgrading DBD::Sybase could fix the problem. The issue could be related to multiple-result sets, or to some other Sybase-specific issue that isn't handled properly by DBIx::ContextualFetch, or maybe something else entirely... Michael Extranet [EMAIL PROTECTED] - 24/07/2006 17:27 To:Philip.Garrett, dbi-users cc:mpeppler Subject:RE: Problem with DBI We are using, DBD::Sybase v1.02_01. The latest one seems to be v1.07. We could try the upgrade but it would be difficult to convince the production group unless we can say for sure that the latest version addresses this problem. cc:ing the author to see if he has something to offer. -Mohan -Original Message- From: Garrett, Philip (MAN-Corporate) [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 8:17 PM To: Palisetti, Krishna_Mohan; dbi-users@perl.org Subject: RE: Problem with DBI Palisetti, Krishna_Mohan wrote: Hi, I'm seeing the following warning message from DBIx::ContextualFetch intermittently. Use of uninitialized value in null operation at /usr/local/lib/perl5/site_perl/5.8.6/DBIx/ContextualFetch.pm line 51. What does it mean? Sorry, I am not in a position to provide a simple test case as I still can't reproduce the problem at will. [EMAIL PROTECTED]:~$ perl -MDBI -e 'DBI-installed_versions;' Perl: 5.008006(i86pc-solaris) OS : solaris (2.10) DBI : 1.48 What version of DBIx::ContextualFetch do you have installed? [EMAIL PROTECTED]:~$ perl -MDBIx::ContextualFetch -le 'print $DBIx::ContextualFetch::VERSION' 1.02 I can't be sure, but it looks like it's probably a bug in the DBD you're using. What driver are you using with this connection? Is it the latest version? Philip This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
RE: Problem with DBI
On Tue, 2006-07-25 at 09:44 -0400, Garrett, Philip (MAN-Corporate)
wrote:
This part of DBIx::ContextualFetch is just a statement handle subclass.
It's trying to call $sth-SUPER::execute() which is where the error is
occurring. I suppose it could be something about DBI instead of
DBD::Sybase, but I use DBIx::ContextualFetch with Oracle and I've never
seen the error.
The offending code:
46 # local $sth-{Taint} leaks in old perls :(
47 sub _untaint_execute {
48 my $sth = shift;
49 my $old_value = $sth-{Taint};
50 $sth-{Taint} = 0;
51 my $ret = $sth-SUPER::execute(@_);
52 $sth-{Taint} = $old_value;
53 return $ret;
54 }
Thanks for the detail.
However, as I've never seen that error with DBD::Sybase on its own and I
don't really know what it refers to there isn't all that much that I can
do at this point.
If the OP can provide me with a trace that illustrates the problem then
it may be possible to identify the issue.
Michael
--
Michael Peppler - Peppler Consulting SaRL
[EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com/
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: DBD::Sybase misleads me?
I suspect that this should really be addressed to a Sybase list. However, what may happen is that the server doesn't have enough network memory available and therefore is not able to allow the client to connect with the 16k packet size. You should probably take a look at the additional network memory sp_configure option, and read the writeup in Chapter 4 of the System Admin Guide (page 142 in my 12.5.2 PDF) Michael Extranet [EMAIL PROTECTED] - 23/06/2006 14:36 To:dbi-users cc: Subject:DBD::Sybase misleads me? I have a commercial program that accesses a Sybase 12.5 server. It has an option to change the packet size of the communucation frame with the server, but you have to know what size you want. Sooo, in my perl program, I connect to the database with DBD::Sybase, execute a sp_configure 'max network packet size' and then I system() the commercial program with the argument -zpkt=whatever I got back. Occasionally, the program responds with DB-Lib ERROR: 20201: Packet size of 16384 not supported -- size of 13824 used instead. severity is 1 The program then dies, but that is their problem - it should disconnect and reconnect properly and I will register te bug with them My question is this what causes this? One minute 16384 is ok and the next its not. DBD::Sybase is CT-LIb based and their program is DB-Lib based. Is that a problem? -- Matthew O. Persico This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: DBD::Sybase misleads me?
The sp_configure option is dynamic, but only affects future connections. It is an upper limit, and the client has to specifically request the larger packet size to get it. Otherwise the default 512 byte packet size is used. Michael Extranet [EMAIL PROTECTED] - 23/06/2006 14:48 To:matthew.persico cc:dbi-users Subject:Re: DBD::Sybase misleads me? What does sp_configure max network packet size affect? The current connection or the entire server? If it's the connection, it simply can't work: The commercial app is forked, and has no relation to DBI's connection, so it creates and uses its own connection (though it seems to fail to set the desired size by itself). It it's the entire server, does the client library assume a certain size or does it asks the server for the current max. packet size? (And why would you want to change that setting?) Alexander On 23.06.2006 14:36, Matthew Persico wrote: I have a commercial program that accesses a Sybase 12.5 server. It has an option to change the packet size of the communucation frame with the server, but you have to know what size you want. Sooo, in my perl program, I connect to the database with DBD::Sybase, execute a sp_configure 'max network packet size' and then I system() the commercial program with the argument -zpkt=whatever I got back. Occasionally, the program responds with DB-Lib ERROR: 20201: Packet size of 16384 not supported -- size of 13824 used instead. severity is 1 The program then dies, but that is their problem - it should disconnect and reconnect properly and I will register te bug with them My question is this what causes this? One minute 16384 is ok and the next its not. DBD::Sybase is CT-LIb based and their program is DB-Lib based. Is that a problem? -- Matthew O. Persico -- Alexander Foken mailto:[EMAIL PROTECTED] http://www.foken.de/alexander/ This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: DBD::Sybase question
Hi,
Yes, I know about that script - but you should still be careful when you
use a binary built with a 12.5.1 client installation against a 15.0
run-time. It would probably be better to rebuild.
Michael
Extranet
[EMAIL PROTECTED] - 25/04/2006 17:13
To: Michael PEPPLER
cc: dbi-users, mthaker, sybperl-l
Subject:Re: DBD::Sybase question
Many thanks for the reply and the information Michael - it's been very
useful.
It may interest you to know that we've successfully been able to run our
regression tests (which use DBD::Sybase 1.00) without changing anything
EXCEPT following the Sybase SDK 15 documentation and running
$SYBASE/OCS-15_0/scripts/lnsyblibs create - which creates soft-links
under $SYBASE/OCS-15_0/lib for backward-compatability (as you quite
rightly
pointed out that Sybase have changed their lib names by adding a 'syb'
suffix to each one - eg. libct.so is now libsybct.so - the soft-links
allow
a preservation reference of 'libct.so').
By the way, please note that there seems to be a bug in
$SYBASE/OCS-15_0/scripts/lnsyblibs as follows:
BUG in red:
createlinks()
{
ls libsyb*.s[o|l] |\
awk '{
print ln -s $1 lib substr($1, 7, length($1) - 6)
}' | sh
}
FIX in blue:
createlinks()
{
ls libsyb*.s[ol] |\
awk '{
print ln -s $1 lib substr($1, 7, length($1) - 6)
}' | sh
}
Once again, many thanks for your valuable feedback.
Regards,
Minesh
[EMAIL PROTECTED]
npparibas.com
To
25/04/2006 07:07 [EMAIL PROTECTED]
cc
dbi-users@perl.org,
[EMAIL PROTECTED]
Subject
Re: DBD::Sybase question
You can interact with an ASE 15 server with a 12.5.1 client with no
particular problems. There may be some issues with the more esoteric
OpenClient functionality, but as DBD::Sybase doesn't use this it shouldn't
be a problem.
So the short answer is that you can keep your current environment and add
the ASE 15 server to the interfaces file.
Moving forward however you should consider upgrading the client and
DBD::Sybase, so to answer your other questions:
- DBD::Sybase 1.00 will not build with OCS 15 due to changes in the
library
names (and maybe other problems as well - I have never tried it).
- A DBD::Sybase binary should only be used at run-time with the same OCS
version that was used to build it (note: EBF changes are OK without a
rebuild)
- To have multiple DBD::Sybase binaries with a single perl installation
you
need to set the PERL5_LIB env. variable or use the use lib directive in
your scripts to point to the directory that holds the DBD::Sybase binary
that you want to use. It is certainly feasible, but you obviously need to
set something up so that these settings are automatic (i.e. you don't want
to have to edit your scripts to set the correct environment :-)
That being said I only have a 15.0 installation here, and use it to
interface with all sorts of Sybase servers (including an antique 4.9.2
server!) and I have yet to see any problems.
Michael
Extranet
[EMAIL PROTECTED] - 24/04/2006 10:14
To:dbi-users, sybperl-l
cc:
Subject:DBD::Sybase question
Hi,
We are conducting a proof of concept to upgrade Sybase ASE 12.5.1 and
OpenClient 12.5.1 to Sybase ASE 15.0 and SDK 15.0 on Solaris 2.8. Our
current environment details are as follows:
Perl 5.005 (5.0 patchlevel 5 subversion 3)
Sybase OC 12.5.1
Sybase ASE 12.5.1
DBI 1.37
DBD::Sybase 1.00
We'd like to retain Sybase 12.5.1 and it's perl environment as described
above but create a new environment for Sybase 15.0.0 and have the
following
questions (any feedback will be greatly appreciated):
- do we need an entirely separate perl, DBI and DBD installation for the
Sybase 15.0.0 side of things?
- do we need DBD::Sybase 1.07 for Sybase 15.0.0
- is there anyway we can use the same perl installation but point it to
either DBD::Sybase 1.00 or DBD::Sybase 1.07
Thanks Regards,
Minesh Thaker
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_
http://www.dstinternational.com
Notice: This e-mail and any attachments are intended only for the
individual
or company to which it is addressed and may contain information which is
privileged, confidential and prohibited from disclosure or unauthorized
use under applicable law. If you are not the intended recipient of this
e-mail, you are hereby notified that any use, dissemination or copying of
this e-mail or the information contained in this e-mail is strictly
prohibited by the sender.
Whilst we run anti-virus software on all internet e-mails we are not
liable
for any loss or damage. The recipient is advised to run their own
anti-virus
software.
If you have received this transmission in error, please return the
material
received to the sender and delete all copies from your system. Thank you.
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord
Re: DBD::Sybase question
You can interact with an ASE 15 server with a 12.5.1 client with no particular problems. There may be some issues with the more esoteric OpenClient functionality, but as DBD::Sybase doesn't use this it shouldn't be a problem. So the short answer is that you can keep your current environment and add the ASE 15 server to the interfaces file. Moving forward however you should consider upgrading the client and DBD::Sybase, so to answer your other questions: - DBD::Sybase 1.00 will not build with OCS 15 due to changes in the library names (and maybe other problems as well - I have never tried it). - A DBD::Sybase binary should only be used at run-time with the same OCS version that was used to build it (note: EBF changes are OK without a rebuild) - To have multiple DBD::Sybase binaries with a single perl installation you need to set the PERL5_LIB env. variable or use the use lib directive in your scripts to point to the directory that holds the DBD::Sybase binary that you want to use. It is certainly feasible, but you obviously need to set something up so that these settings are automatic (i.e. you don't want to have to edit your scripts to set the correct environment :-) That being said I only have a 15.0 installation here, and use it to interface with all sorts of Sybase servers (including an antique 4.9.2 server!) and I have yet to see any problems. Michael Extranet [EMAIL PROTECTED] - 24/04/2006 10:14 To:dbi-users, sybperl-l cc: Subject:DBD::Sybase question Hi, We are conducting a proof of concept to upgrade Sybase ASE 12.5.1 and OpenClient 12.5.1 to Sybase ASE 15.0 and SDK 15.0 on Solaris 2.8. Our current environment details are as follows: Perl 5.005 (5.0 patchlevel 5 subversion 3) Sybase OC 12.5.1 Sybase ASE 12.5.1 DBI 1.37 DBD::Sybase 1.00 We'd like to retain Sybase 12.5.1 and it's perl environment as described above but create a new environment for Sybase 15.0.0 and have the following questions (any feedback will be greatly appreciated): - do we need an entirely separate perl, DBI and DBD installation for the Sybase 15.0.0 side of things? - do we need DBD::Sybase 1.07 for Sybase 15.0.0 - is there anyway we can use the same perl installation but point it to either DBD::Sybase 1.00 or DBD::Sybase 1.07 Thanks Regards, Minesh Thaker _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ http://www.dstinternational.com Notice: This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. Whilst we run anti-virus software on all internet e-mails we are not liable for any loss or damage. The recipient is advised to run their own anti-virus software. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. Thank you. This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: Can't connect to Sybase Rep server
Here's the code that checks to see if the remote server understands the
ct_option call.
/* Check to see if the server supports the ct_option() call */
if(!imp_dbh-optSupported) {
CS_BOOL val;
CS_RETCODE ret = ct_capability(connection, CS_GET,
CS_CAP_REQUEST,
CS_OPTION_GET, (CS_VOID*)val);
if(DBIc_DBISTATE(imp_dbh)-debug = 3)
PerlIO_printf(DBIc_LOGPIO(imp_dbh), syb_db_login() -
checking for ct_option support (ret = %d, val = %d)\n, ret, val);
if(ret != CS_SUCCEED || val == CS_FALSE)
imp_dbh-optSupported = 0;
else
imp_dbh-optSupported = 1;
if(DBIc_DBISTATE(imp_dbh)-debug = 3)
PerlIO_printf(DBIc_LOGPIO(imp_dbh), syb_db_login() -
ct_option is %ssupported\n, imp_dbh-optSupported == 1 ?:not );
}
BTW - which version of DBI are you using?
Michael
Extranet
[EMAIL PROTECTED] - 01/03/2006 18:57
To: dbi-users
cc:
Subject:Re: Can't connect to Sybase Rep server
Edited for brevity
On 3/1/06, Matthew Persico [EMAIL PROTECTED] wrote:
On 3/1/06, Matthew Persico [EMAIL PROTECTED] wrote:
On 2/28/06, Matthew Persico [EMAIL PROTECTED] wrote:
Message d'origine
De: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Date: mar. 28.02.2006 07:54
À: [EMAIL PROTECTED]
Cc: dbi-users@perl.org
Objet: Re: Can't connect to Sybase Rep server
This is a known problem, and has been fixed in either 1.07 or
1.07_01.
Must be 1.07_01 'cause I am running 1.07. I will download and try
it.
is the _01 designation ok for production use?
Better yet, can anyone point me to where 1.07_01 lives? It's not on
CPAN.
Never mind:
http://www.peppler.org/downloads/
I did a diff on 1.07 vs 1.07_01 and I didn't notice any differences
that would indicate this problem being solved.
I also diffed 1.00 vs 1.07_01 and didn't notice any differences that
would indicate this problem being solved.
What should I be looking for?
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
-
Ce message et toutes les pieces jointes (ci-apres le
message) sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
Re: Using Kerberos enabled connections with Sybase
On 2/23/06, Chuck Fox [EMAIL PROTECTED] wrote: Hello fellow dbi-users. I am attempting to connect to a 12.5 Sybase server using kerberos enabled connections. My isql and sqsh both correctly connect (sqsh needed a small fix to load the security ). However, I am unable to get DBD::Sybase to load the security modules. It appears that you have to pass the syb_kerberos_serverprincipal through the attributes as opposed to using the DSN. Should the check be against kerberosPrincipal instead of kerbGetTicket ? The syb_kerberos_serverprincipal is a reference to a subroutine that fetches the principal. It was coded so that you could have a parametrized way of retrieving the principal. That being said there are other problems with loading the Kerberos libs and DBD::Sybase that I'm looking into at the moment. Michael
Re: Can't connect to Sybase Rep server
This is a known problem, and has been fixed in either 1.07 or 1.07_01.
DBD::Sybase tries to see if chained transactions are supported at startup,
and tries to find the @@version of the server. Both of these requests fail
against a replication server, but the failure is expected, so should simply
be hidden from the user...
Michael
Extranet
[EMAIL PROTECTED] - 27/02/2006 20:39
To:dbi-users, Michael PEPPLER
cc:
Subject:Can't connect to Sybase Rep server
This simple test program:
use strict;
use warnings;
use DBI;
my $dbh = DBI-connect('dbi:Sybase:server=REPP', 'REPP_login',
'REPP_passwd', {RaiseError = 1});
my $dummy = 6;
causes this:
Server message number=17001 severity=10 state=0 line=0 server=REPP
text=No SRV_OPTION handler installed.OpenClient message: LAYER = (1)
ORIGIN = (1) SEVERITY = (1) NUMBER = (183)
Server REPP, database
Message String: ct_options(): user api layer: external error: An error
was returned from the server while setting the options, check the
server message for details.
Server message number=2056 severity=12 state=0 line=0 server=REPP
text=Line 1, character 8: Incorrect syntax with 'select'.
[EMAIL PROTECTED] (DEV, uid=8030(persicom) gid=200(develop) depth=0)
using Perl 5.6.1, DBI 1.48 and DBD::Sybase 1.07.
However, when using Perl 5.6.1, DBI 1.37 and DBD::Sybase 1.00, I get
no error message.
What DBI trace flags/envars do I neet to set in order to diagnose this?
--
Matthew O. Persico
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
-
Ce message et toutes les pieces jointes (ci-apres le
message) sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
Re: DBD::Sybase + freetds from Linux to Microsoft SQL Server 2000 contest
On Sat, 2006-02-04 at 22:13 -0600, JupiterHost.Net wrote:
Hello list,
I'm about to go nuts trying to connect to Microsoft SQL Server 2000 from
a linux machine.
I'll pay $20 to the first person who can get me over this last hump,
seriously I'll paypal it to you, maybe more if the solution is had
quickly. No joke, I will pay :)
Here's what I have:
As root I:
1) download and untarred freetds (v0.63)and went into the dir:
./configure --prefix=/opt/freetds
make
make install
2) Dowloaded an unatarred DBD-Sybase (v1.07) and went into the dir:
export SYBASE=/opt/freetds
perl Makefile.PL
make
make install
This connects:
# /opt/freetds/bin/tsql -H 1.2.3.4 -p 1433 -U howdy -Pdoody
locale is en_US.UTF-8
locale charset is UTF-8
1 select convert( varchar(30), getdate(), 120 ) as No
2 go
No
2006-02-04 21:40:56
1
Now what do I need to do to
my $dbh = DBI-connect(?) or die DBI-errstr();
and how can I do a simple test query (verision or date, whatever) and
print the results?
Add an entry in the /etc/freetds.conf file (or wherever the freetds.conf
file is located) that maps to your server - let's call this MYSERVER.
Now the connect() call:
$dbh = DBI-connect('dbi:Sybase:server=MYSERVER', );
Of course you should already have seen this and added the entry to
freetds.conf when you were building DBD::Sybase as it is required for
the make test phase.
Michael
--
Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com/
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: trouble loading DBD::Sybase 1.05 on tiger, MacOSX 10.4.4
Take a look at this link and let me know if that fixes things: http://groups.google.ch/group/sybase.public.macosx/browse_thread/thread/58a37c62080397dd/d22a38db2705d421?lnk=stq=dbd%3A%3Asybase+macosxrnum=1hl=fr#d22a38db2705d421 Michael Extranet [EMAIL PROTECTED] - 31/01/2006 21:25 To: dbi-users cc: Subject:trouble loading DBD::Sybase 1.05 on tiger, MacOSX 10.4.4 Hi, I had trouble loading DBD::Sybase on MacOSx 10.4.4.. Any ideas boehme:~/DBD-Sybase-1.05_02 boehme$ perl Makefile.PL Sybase OpenClient 12.5.1 ASE Edition found. By default DBD::Sybase 1.05 and later use the 'CHAINED' mode (where available) when 'AutoCommit' is turned off. Versions 1.04 and older instead managed the transactions explicitly with a 'BEGIN TRAN' before the first DML statement. Using the 'CHAINED' mode is preferable as it is the way that Sybase implements AutoCommit handling for both its ODBC and JDBC drivers. Use 'CHAINED' mode by default (Y/N) [Y]: n Running in threaded mode - looking for _r libraries... Found -lsybct_r for -lsybct Found -lsybcs_r for -lsybcs Found -lsybtcl_r for -lsybtcl Found -lsybcomn_r for -lsybcomn Found -lsybintl_r for -lsybintl Found -lsybblk_r for -lsybblk Found -lsybsrv_r for -lsybsrv The DBD::Sybase module need access to a Sybase server to run the tests. To clear an entry please enter 'undef' Sybase server to use (default: SYBASE): tatung User ID to log in to Sybase (default: sa): ^C boehme:~/DBD-Sybase-1.05_02 boehme$ perl Makefile.PL Sybase OpenClient 12.5.1 ASE Edition found. By default DBD::Sybase 1.05 and later use the 'CHAINED' mode (where available) when 'AutoCommit' is turned off. Versions 1.04 and older instead managed the transactions explicitly with a 'BEGIN TRAN' before the first DML statement. Using the 'CHAINED' mode is preferable as it is the way that Sybase implements AutoCommit handling for both its ODBC and JDBC drivers. Use 'CHAINED' mode by default (Y/N) [Y]: n Running in threaded mode - looking for _r libraries... Found -lsybct_r for -lsybct Found -lsybcs_r for -lsybcs Found -lsybtcl_r for -lsybtcl Found -lsybcomn_r for -lsybcomn Found -lsybintl_r for -lsybintl Found -lsybblk_r for -lsybblk Found -lsybsrv_r for -lsybsrv The DBD::Sybase module need access to a Sybase server to run the tests. To clear an entry please enter 'undef' Sybase server to use (default: SYBASE): TATUNG User ID to log in to Sybase (default: sa): sa Password (default: undef): redpill Sybase database to use on TATUNG (default: undef): test * Writing login information, including password, to file PWD. Checking if your kit is complete... Looks good Using DBI 1.48 (for perl 5.008006 on darwin-thread-multi-2level) installed in /Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DBI/ Writing Makefile for DBD::Sybase boehme:~/DBD-Sybase-1.05_02 boehme$ make cp dbd-sybase.pod blib/lib/DBD/dbd-sybase.pod cp Sybase.pm blib/lib/DBD/Sybase.pm /usr/bin/perl -p -e s/~DRIVER~/Sybase/g /Library/Perl/5.8.6/darwin- thread-multi-2level/auto/DBI//Driver.xst Sybase.xsi /usr/bin/perl /System/Library/Perl/5.8.6/ExtUtils/xsubpp -typemap / System/Library/Perl/5.8.6/ExtUtils/typemap Sybase.xs Sybase.xsc mv Sybase.xsc Sybase.c cc -c -I/Applications/Sybase/System/OCS-12_5/include - DNO_CHAINED_TRAN=1 -I/Library/Perl/5.8.6/darwin-thread-multi-2level/ auto/DBI -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno- strict-aliasing -I/usr/local/include -Os -DVERSION=\1.05_02\ - DXS_VERSION=\1.05_02\ -I/System/Library/Perl/5.8.6/darwin-thread- multi-2level/CORE Sybase.c cc -c -I/Applications/Sybase/System/OCS-12_5/include - DNO_CHAINED_TRAN=1 -I/Library/Perl/5.8.6/darwin-thread-multi-2level/ auto/DBI -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno- strict-aliasing -I/usr/local/include -Os -DVERSION=\1.05_02\ - DXS_VERSION=\1.05_02\ -I/System/Library/Perl/5.8.6/darwin-thread- multi-2level/CORE dbdimp.c dbdimp.c: In function '_dbd_rebind_ph': dbdimp.c:4764: warning: passing argument 2 of 'to_binary' from incompatible pointer type Running Mkbootstrap for DBD::Sybase () chmod 644 Sybase.bs rm -f blib/arch/auto/DBD/Sybase/Sybase.bundle LD_RUN_PATH= env MACOSX_DEPLOYMENT_TARGET=10.3 cc -L/Applications/ Sybase/System/OCS-12_5/lib -bundle -undefined dynamic_lookup -L/usr/ local/lib Sybase.o dbdimp.o -o blib/arch/auto/DBD/Sybase/ Sybase.bundle -L/Applications/Sybase/System/OCS-12_5/lib -lsybct_r - lsybcs_r -lsybtcl_r -lsybcomn_r -lsybintl_r -lsybblk_r -lsybsrv_r - ldl -lm /usr/bin/ld: warning multiple definitions of symbol _dlclose /Applications/Sybase/System/OCS-12_5/lib/libsybtcl_r.a(dlopen.o) definition of _dlclose in section (__TEXT,__text) /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/../../../libdl.dylib (dyldAPIsInLibSystem.o) definition of _dlclose /usr/bin/ld: warning multiple definitions of symbol _dlerror /Applications/Sybase/System/OCS-12_5/lib/libsybtcl_r.a(dlopen.o) definition of _dlerror in section (__TEXT,__text)
Re: mod_perl2 DBI handle freshining problem solved once and for all...
For this purpose, connected and pingable are the same thing. Yes and no. If you can't ping the server, but the TCP socket is still open, that means you essentially have this TCP connection to the server that's not being used, in an open state, for the rest of the lifetime of your apache server instance. This could be a Bad Thing, say, if it's in mid-transaction, keeping a table lock open... Sorry, but this sounds like total conjecture to me. You have to expect certain basic things to work, and one of them is that a connection which can't be ping'ed is not holding a table lock. If it is, this is a much lower-level bug than DBI should try to deal with. I'll add one more thing - for some drivers a call to $dbh-ping() will generate a *new* connection *if* the driver thinks that the $dbh is currently active (ie has an active $sth) - DBD::Sybase in particular, but I suspect that other drivers that don't support multiple active statements on a single physical connection will have the same behavior. Michael This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: trouble loading DBD::Sybase 1.05 on tiger, MacOSX 10.4.4
Please post the build log (perl Makefile.PL and make) Thanks, Michael Extranet [EMAIL PROTECTED] - 01/02/2006 19:34 To:dbi-users cc: Subject:Re: trouble loading DBD::Sybase 1.05 on tiger, MacOSX 10.4.4 Hi, I tried your solution on a newer version (1.07) of the install..it did not help. Here is the output of the make test; this is real show stopper for us..any ideas??? make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/autocommitok 1/9# Failed test (t/autocommit.t at line 18) # Tried to use 'DBD::Sybase'. t/autocommitNOK 2# Error: Can't load 'blib/arch/auto/DBD/Sybase/Sybase.bundle' for module DBD::Sybase: dlopen(blib/arch/auto/DBD/Sybase/Sybase.bundle, 2): Symbol not found: _cs_conv_mult # Referenced from: blib/arch/auto/DBD/Sybase/Sybase.bundle # Expected in: dynamic lookup # at (eval 4) line 2 # Compilation failed in require at (eval 4) line 2. Had to create DBD::Sybase::dr::imp_data_size unexpectedly at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Use of uninitialized value in subroutine entry at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Had to create DBD::Sybase::db::imp_data_size unexpectedly at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Use of uninitialized value in subroutine entry at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Undefined subroutine DBD::Sybase::db::_login called at blib/lib/DBD/Sybase.pm line 94. # Looks like you planned 9 tests but only ran 2. # Looks like your test died just after 2. t/autocommitdubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 2-9 Failed 8/9 tests, 11.11% okay t/base..install_driver(Sybase) failed: Can't load '/Users/mks/Desktop/DBI_Inst/DBD-Sybase-1.07 /blib/arch/auto/DBD/Sybase/Sybase.bundle' for module DBD::Sybase: dlopen(/Users/mks/Desktop/DBI_Inst/DBD-Sybase-1.07 /blib/arch/auto/DBD/Sybase/Sybase.bundle, 2): Symbol not found: _cs_conv_mult Referenced from: /Users/mks/Desktop/DBI_Inst/DBD-Sybase-1.07 /blib/arch/auto/DBD/Sybase/Sybase.bundle Expected in: dynamic lookup at (eval 3) line 3 Compilation failed in require at (eval 3) line 3. Perhaps a required shared library or dll isn't installed where expected at t/base.t line 18 t/base..dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 4-5 Failed 2/5 tests, 60.00% okay t/exec..ok 1/22# Failed test (t/exec.t at line 18) # Tried to use 'DBD::Sybase'. # Error: Can't load 'blib/arch/auto/DBD/Sybase/Sybase.bundle' for module DBD::Sybase: dlopen(blib/arch/auto/DBD/Sybase/Sybase.bundle, 2): Symbol not found: _cs_conv_mult # Referenced from: blib/arch/auto/DBD/Sybase/Sybase.bundle # Expected in: dynamic lookup # at (eval 4) line 2 # Compilation failed in require at (eval 4) line 2. t/exec..NOK 2Had to create DBD::Sybase::dr::imp_data_size unexpectedly at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Use of uninitialized value in subroutine entry at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Had to create DBD::Sybase::db::imp_data_size unexpectedly at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Use of uninitialized value in subroutine entry at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Undefined subroutine DBD::Sybase::db::_login called at blib/lib/DBD/Sybase.pm line 94. # Looks like you planned 22 tests but only ran 2. # Looks like your test died just after 2. t/exec..dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests 2-22 Failed 21/22 tests, 4.55% okay t/fail..ok 1/12# Failed test (t/fail.t at line 16) # Tried to use 'DBD::Sybase'. t/fail..NOK 2# Error: Can't load 'blib/arch/auto/DBD/Sybase/Sybase.bundle' for module DBD::Sybase: dlopen(blib/arch/auto/DBD/Sybase/Sybase.bundle, 2): Symbol not found: _cs_conv_mult # Referenced from: blib/arch/auto/DBD/Sybase/Sybase.bundle # Expected in: dynamic lookup # at (eval 4) line 2 # Compilation failed in require at (eval 4) line 2. Had to create DBD::Sybase::dr::imp_data_size unexpectedly at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Use of uninitialized value in subroutine entry at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Had to create DBD::Sybase::db::imp_data_size unexpectedly at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Use of uninitialized value in subroutine entry at /Library/Perl/5.8.6/darwin-thread-multi-2level/DBI.pm line 1182. Undefined subroutine DBD::Sybase::db::_login called at blib/lib/DBD/Sybase.pm line 94. # Looks like you planned 12 tests but only ran 2. # Looks like your test died just after 2. t/fail..dubious Test returned status 255 (wstat 65280, 0xff00) DIED. FAILED tests
Re: DBD::Sybase Stored Proc argument placeholders
Yes. Michael Extranet [EMAIL PROTECTED] - 03/01/2006 02:14 To:dbi-users cc: Subject:DBD::Sybase Stored Proc argument placeholders In 1.00 (which I have in production) Stored Proc argument placeholders are marked as experimental. By 1.07, the designation has been removed. Can I safely use Stored Proc argument placeholders in DBD::Sybase 1.00? Happy New Year -- Matthew O. Persico This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
RE: DBD-Sybase 1.07, FreeTDS 0.63, HPUX 11.11: Build problem (maketest)
These errors are to be expected. Your binaries should be fine. Michael Extranet [EMAIL PROTECTED] - 27/12/2005 21:36 Please respond to [EMAIL PROTECTED] To:mpeppler cc:dbi-users Subject:RE: DBD-Sybase 1.07, FreeTDS 0.63, HPUX 11.11: Build problem (maketest) Michael, Thanks for the reply. I guess I assumed that since TDS supports the host+port that the Sybase DBD would also. After your reply, I tried the 'make test' again, with each ENV variable set that I could think of, and correct values in PWD. Still, it was not referencing the proper info. Next, I hardcoded the correct values into each script in the t directory, and got it to complete, then installed it. At this point, since many tests failed, I am wondering if I have a useful Sybase-DBD module ? I am attaching the output of the last 'make test'. Thanks again for your assistance. Rick -Original Message- From: Michael Peppler [mailto:[EMAIL PROTECTED] Sent: Thursday, December 22, 2005 11:51 AM To: [EMAIL PROTECTED] Cc: dbi-users@perl.org Subject: Re: DBD-Sybase 1.07, FreeTDS 0.63, HPUX 11.11: Build problem (maketest) On Wed, 2005-12-21 at 11:34 -0500, Rick Frink wrote: Hello, I am trying to use freetds (0.63) as the library for DBD::Sybase (1.07) to communicate with MS SQL 2000 servers. After the build, it does not appear that DBD::Sybase reconizes the freetds config file (/usr/local/freetds/freetds.conf), in particular for defining which host+port make up the Server. I even tried it in the local `pwd`. host+Most importantly, 'make test' fails and will not complete the install. Also, the connect method complains about accepting host+port arguments, and seems to want a Server, only. The manpage says it accepts host+port. If you read the man page completely you'll notice that the host+port connect() argument are only supported when using *Sybase* openclient 12.5.1 or later. It is not supported with FreeTDS. I am operating in a HPUX 11.11 environment, and have the DBD::Sybase statically linked using the freetds libs. Without passing the 'make test' target, DBD::Sybase does not fully install (complains about not found in @INC). I am using Perl 5.8.7, and DBI-1.48. The make test appears to fail because it tries to use a non-existent (standard) Sybase server and connect params. Did you give it a valid server name during the configuration phase of the build? Is that server correctly defined in the freetds.conf file? Is the SYBASE env. variable set correctly to point at the FreeTDS installation? Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com/ Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html (See attached file: SYBASE-DBD-make_test_9.log) This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie. SYBASE-DBD-make_test_9.log Description: Binary data
Re: DBD-Sybase 1.07, FreeTDS 0.63, HPUX 11.11: Build problem (make test)
On Wed, 2005-12-21 at 11:34 -0500, Rick Frink wrote: Hello, I am trying to use freetds (0.63) as the library for DBD::Sybase (1.07) to communicate with MS SQL 2000 servers. After the build, it does not appear that DBD::Sybase reconizes the freetds config file (/usr/local/freetds/freetds.conf), in particular for defining which host+port make up the Server. I even tried it in the local `pwd`. Most importantly, 'make test' fails and will not complete the install. Also, the connect method complains about accepting host+port arguments, and seems to want a Server, only. The manpage says it accepts host+port. If you read the man page completely you'll notice that the host+port connect() argument are only supported when using *Sybase* openclient 12.5.1 or later. It is not supported with FreeTDS. I am operating in a HPUX 11.11 environment, and have the DBD::Sybase statically linked using the freetds libs. Without passing the 'make test' target, DBD::Sybase does not fully install (complains about not found in @INC). I am using Perl 5.8.7, and DBI-1.48. The make test appears to fail because it tries to use a non-existent (standard) Sybase server and connect params. Did you give it a valid server name during the configuration phase of the build? Is that server correctly defined in the freetds.conf file? Is the SYBASE env. variable set correctly to point at the FreeTDS installation? Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com/ Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: Bareword DBI::SQL_INTEGER not allowed while strict subs
One way to solve it is to do: use DBI qw(:sql_types); Michael Extranet [EMAIL PROTECTED] - 12/12/2005 00:45 To:dbi-users cc: Subject:Bareword DBI::SQL_INTEGER not allowed while strict subs I am new to DBI, Perl, and SQL and I am currently trying to piece together a group of bioinformatic programs. In running the database element of the package, I recieve a number of : Bareword DBI::SQL_INTEGER not allowed while strict subs in use errors (a full listing of the error is pasted below). Does anyone have experience with this error and/or suggestions on how i might resolve it? I am truly a novice, 3 days in, so simple explanations would be especially appreciated. I'm running : Perl 5.8.6 dbi-pm 5.8.6 PostgreSQL -perl-586 Mac OS 10.4.2 Bareword DBI::SQL_INTEGER not allowed while strict subs in use at /sw/lib/perl5/5.8.6/darwin-thread-multi-2level/DBD/Pg.pm line 1168. Bareword DBI::SQL_SMALLINT not allowed while strict subs in use at /sw/lib/perl5/5.8.6/darwin-thread-multi-2level/DBD/Pg.pm line 1168. Bareword DBI::SQL_DECIMAL not allowed while strict subs in use at /sw/lib/perl5/5.8.6/darwin-thread-multi-2level/DBD/Pg.pm line 1168. Bareword DBI::SQL_FLOAT not allowed while strict subs in use at / sw/lib/perl5/5.8.6/darwin-thread-multi-2level/DBD/Pg.pm line 1168. Bareword DBI::SQL_REAL not allowed while strict subs in use at / sw/lib/perl5/5.8.6/darwin-thread-multi-2level/DBD/Pg.pm line 1168. Bareword DBI::SQL_DOUBLE not allowed while strict subs in use at / sw/lib/perl5/5.8.6/darwin-thread-multi-2level/DBD/Pg.pm line 1168. Bareword DBI::SQL_NUMERIC not allowed while strict subs in use at /sw/lib/perl5/5.8.6/darwin-thread-multi-2level/DBD/Pg.pm line 1168. Compilation failed in require at /Users/TheBucket/lib/Perl/PartiGene/ PG_db.pm line 6. BEGIN failed--compilation aborted at /Users/TheBucket/lib/Perl/ PartiGene/PG_db.pm line 6. Compilation failed in require at /Users/TheBucket/genome/bin/ PartiGene_db.pl line 4. BEGIN failed--compilation aborted at /Users/TheBucket/genome/bin/ PartiGene_db.pl line 4. Patrick Danley, Ph.D. Postdoctoral Researcher Department of Biology University of Maryland phone 301.405.8303 fax 301.314.9358 email [EMAIL PROTECTED] http://www.life.umd.edu/biology/shawlab/patrickdanley This message and any attachments (the message) is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. - Ce message et toutes les pieces jointes (ci-apres le message) sont etablis a l'intention exclusive de ses destinataires et sont confidentiels. Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur. Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer l'integrite de ce message, BNP PARIBAS (et ses filiales) decline(nt) toute responsabilite au titre de ce message, dans l'hypothese ou il aurait ete modifie.
Re: Problem loading DBD::Sybase
On Thu, 2005-11-03 at 21:10 +0100, Michael Peppler wrote: On Thu, 2005-11-03 at 11:53 -0500, [EMAIL PROTECTED] wrote: I have problem loading the DBD-Sybase-1.07 on Unix/Solaris 8 OS, SUN Fire V880 hardware. The perl Makefile.PL and the make command runs fine, but the make test command fails. The problem here is that DBD::Sybase currently depends on the libblk.a library (the bulk-copy calls). This library isn't always installed along with the server, in particular on mixed 64/32 bit environments. I have just placed DBD::Sybase 1.07_01 in http://www.peppler.org/downloads. This version should detect the absence of the blk library, and build a version of DBD::Sybase that doesn't use these calls. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com/ Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: Problem loading DBD::Sybase
On Thu, 2005-11-03 at 11:53 -0500, [EMAIL PROTECTED] wrote: I have problem loading the DBD-Sybase-1.07 on Unix/Solaris 8 OS, SUN Fire V880 hardware. The perl Makefile.PL and the make command runs fine, but the make test command fails. The problem here is that DBD::Sybase currently depends on the libblk.a library (the bulk-copy calls). This library isn't always installed along with the server, in particular on mixed 64/32 bit environments. The solution right now is to either try to find the library (it is available in the full OpenClient SDK, for example), or use DBD::Sybase 1.04. I will add a configuration option to skip the BLK calls if the library is unavailable in a future version. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer - TeamSybase: http://www.teamsybase.com/ Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: DBI dies on exit
I build DBD::Oracle with instantclient on linux with no particular problems
after following one of the recipies that I found googling for it.
On the other hand I couldn't get this to work on HP-UX, always getting the
OCIClientInitialize error, no matter which combinations of env. variables
and perl configs I tried.
Michael
Extranet
[EMAIL PROTECTED] - 26/09/2005 21:59
To:Alan.Burlison
cc:Tim.Bunce, dbi-users
Subject:Re: DBI dies on exit
On Mon, Sep 26, 2005 at 04:03:08PM +0100, Alan Burlison wrote:
I've poked at this a bit more - if I install the full client it works
OK, which suggests there is something odd in the way the client shared
objects are being linked - a full install relinks the .so files but the
instant client install doesn't.
Isn't the instant client .so separate from the 'full client' .so?
(I've not looked in ages. I need to fire up my old [cough] Solaris
box and refresh it so I can see what's going on for myself. Might not
happen this week though.)
I'll try dropping the relinked shared
objects into the instant client tree and see if that makes the problem
go away.
Tim, has there been any progress on getting DBD::Oracle to work with an
Instant Client install? How much work do you think it is, I might be
persuaded to produce a patch ;-)
Some guys at pythian.com are working on it now but it (has been) proving
slow going. There seems to be more progress now. Hopefully they'll be
an updated subversion branch by the end of the week.
Tim.
--
Alan Burlison
--
Anyone seen this?
--
#!/usr/perl5/bin/perl
use DBI;
my $dbh = DBI-connect('dbi:Oracle:foo', 'bar', 'baz');
$dbh-disconnect();
--
Out of memory!
Callback called exit.
END failed--call queue aborted.
The environment is Solaris 11 on AMD64, using the latest Oracle 32-bit
instantclient and DBD::Oracle 1.16. The script is barfing in
perl_destroy(), i.e. after the disconnect() statement. Before I get
the
rubber gloves out, has anyone seen anything similar?
Nope.
Callback called exit is very odd but may just be a symptom of Out of
memory ocuring during perl_destroy(). But then that, in itself, is odd.
You'll need the gloves on for this one...
Tim.
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
-
Ce message et toutes les pieces jointes (ci-apres le
message) sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
Re: DBI/Sybase problem
On Wed, 2005-08-24 at 14:09 -0400, Anderson, James H (Company IT) wrote: For a given server, dbconnect works in most cases, but fails for a specific userid/pswd. However, using isql I can connect to the server using the userid/pswd that hangs when used in DBI. Off hand I don't see why that would happen. If you can connect with isql you should be able to connect with DBD::Sybase, as long as your environment is the same. Try running this with DBI-trace(5) and send me (not the list) the output. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
DBD::Oracle, Instantclient and HP-UX...
Hi,
I'm not exactly new to DBI, but I am *very* new to Oracle, so please bear
with me...
I'm trying to build DBD::Oracle on an HP-UX (11.11) box with the 32bit
instantclient package, and while the build works the make test fails, and
my googling has failed to turn up any solutions.
I've patched the Makefile.PL so that the include files and lib files are
found, but the version detection doesn't appear to work.
If I build with perl Makefile.PL -l I get the following error during
make test:
[EMAIL PROTECTED]:/pvar/dba/src/DBD-Oracle-1.16 $perl -Mblib t/10general.t
1..31
DBI connect('','ops$pepm/mike',...) failed: (UNKNOWN OCI STATUS 1804)
OCIInitialize. Check ORACLE_HOME and NLS settings etc. at t/10general.t
line 12
Undefined subroutine main::BAILOUT called at t/10general.t line 15.
# Looks like your test died before it could output anything.
If I try to force the client version to 10.x with -V 10.0 I get:
[EMAIL PROTECTED]:/pvar/dba/src/DBD-Oracle-1.16 $perl -Mblib t/10general.t
1..31
DBI connect('','ops$pepm/mike',...) failed: ERROR OCIEnvNlsCreate (check
ORACLE_HOME and NLS settings etc.) at t/10general.t line 12
I suspect that it's something fairly simple, but I can't seem to find the
right incantation to get it to work.
Thanks!
Michael
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
-
Ce message et toutes les pieces jointes (ci-apres le
message) sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
RE: [dbi] DBD::Oracle, Instantclient and HP-UX...
Hi Lincoln,
Thanks for the advice.
Yes, I did build my own copy of perl (5.8.7), and the build itself appears
fine - certainly there are no missing symbols, etc. in the Oracle.sl file,
and the DBD::Oracle module loads correctly.
Like I said the problem appears to be with the initialization
(OCIEnvNlsCreate fails). Unsetting ORACLE_HOME doesn't solve the problem
for me.
I don't know enogh about this to figure out if this is a local config
problem or if it's a (possible) bug in this version of instantclient
(10.1.0.3 for HP-UX PARisc 32bit)
Michael
Internet
[EMAIL PROTECTED] - 19/08/2005 13:57
Please respond to [EMAIL PROTECTED]
To:Michael PEPPLER
cc:martin.evans, dbi-users
Subject:RE: [dbi] DBD::Oracle, Instantclient and HP-UX...
Tree setting SHLIB_PATH to the same value as LD_LIBRARY_PATH. Try doing
this before you build DBD::Oracle. (You are doing this with a perl you
have built right?)
If/when you get it work, try patching Makefile.PL to find the libraries
and includes so that it builds the right Makefile, if you get that work,
and send the patch to me or to Tim.
Lincoln
On Fri, 2005-08-19 at 11:16 +0200, [EMAIL PROTECTED] wrote:
Thanks Martin,
Unfortunately unsetting ORACLE_HOME didn't fix that problem (i.e.
OCIEnvCreate still fails).
Michael
Extranet
[EMAIL PROTECTED] - 19/08/2005 10:43
To: dbi-users
cc:
Subject:RE: [dbi] DBD::Oracle, Instantclient and HP-UX...
Michael,
I think with InstantClient OCIEnvCreate fails if you set ORACLE_HOME. You
need
to make sure libclntsh.so is on your dynamic linker search path
(LD_LIBRARY_PATH) and do /not/ set ORACLE_HOME.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
Development
On 19-Aug-2005 [EMAIL PROTECTED] wrote:
Hi,
I'm not exactly new to DBI, but I am *very* new to Oracle, so please
bear
with me...
I'm trying to build DBD::Oracle on an HP-UX (11.11) box with the 32bit
instantclient package, and while the build works the make test fails,
and
my googling has failed to turn up any solutions.
I've patched the Makefile.PL so that the include files and lib files
are
found, but the version detection doesn't appear to work.
If I build with perl Makefile.PL -l I get the following error during
make test:
[EMAIL PROTECTED]:/pvar/dba/src/DBD-Oracle-1.16 $perl -Mblib
t/10general.t
1..31
DBI connect('','ops$pepm/mike',...) failed: (UNKNOWN OCI STATUS 1804)
OCIInitialize. Check ORACLE_HOME and NLS settings etc. at t/10general.t
line 12
Undefined subroutine main::BAILOUT called at t/10general.t line 15.
# Looks like your test died before it could output anything.
If I try to force the client version to 10.x with -V 10.0 I get:
[EMAIL PROTECTED]:/pvar/dba/src/DBD-Oracle-1.16 $perl -Mblib
t/10general.t
1..31
DBI connect('','ops$pepm/mike',...) failed: ERROR OCIEnvNlsCreate
(check
ORACLE_HOME and NLS settings etc.) at t/10general.t line 12
I suspect that it's something fairly simple, but I can't seem to find
the
right incantation to get it to work.
Thanks!
Michael
This message and any attachments (the message) is
intended solely for the addressees and is confidential.
If you receive this message in error, please delete it and
immediately notify the sender. Any use not in accord with
its purpose, any dissemination or disclosure, either whole
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message.
BNP PARIBAS (and its subsidiaries) shall (will) not
therefore be liable for the message if modified.
-
Ce message et toutes les pieces jointes (ci-apres le
message) sont etablis a l'intention exclusive de ses
destinataires et sont confidentiels. Si vous recevez ce
message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce
message non conforme a sa destination, toute diffusion
ou toute publication, totale ou partielle, est interdite, sauf
autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce
message, dans l'hypothese ou il aurait ete modifie.
Re: Installing DBD::Sybase
On Wed, 2005-08-17 at 11:17 -0400, Jamie Amundson wrote: When I install DBD::Sybase I get the following error, when running make. make: *** No rule to make target `/usr/lib/perl5/5.8.6 /i386-linux/CORE/EXTERN.h', needed by `Sybase.o'. STOP. /usr/bin/make -- NOT OK What am I missisng? It looks like your perl installation is broken... Can you build other extensions that require compilation? Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
ANNOUNCE: DBD::Sybase 1.06
I have just uploaded DBD::Sybase 1.06 to CPAN.
This is a bug fix release.
Known problems:
If you build DBD::Sybase with the Beta 15.0 OpenClient libraries then 4
tests in t/xblk.t will fail. I have not yet had time to investigate
fully.
Doing
$sth = $dbh-prepare(...);
$dbh-{AutoCommit} = 0;
fails because DBD::Sybase won't let you change AutoCommit on a DBH that
has active children.
From the CHANGES file:
Release 1.06
Fix off-by-one error for ISO date format.
Clear error/warning when connecting to a Replication Server.
Fix AutoCommit off behavior when CHAINED mode is turned off.
Fix $dbh-begin_work() behavior.
Note: This version fails 4 tests in t/xblk.t when building
against the 15.0 Beta OCS libraries.
Bug Fixes
582 - ISO date formatting off by one for months.
591 - NUM_OF_PARAMS isn't handled properly
593 - Connection can become unusable due a bug in
get_server_version().
597 - Prepared stored procs with placeholders return
corrupted recordset on second fetch.
599 - The call to prepare also executes the statement.
600 - $sth-finish sometimes fails to properly clean up the
handle.
Michael
The uploaded file
DBD-Sybase-1.06.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/ME/MEWP/DBD-Sybase-1.06.tar.gz
size: 188863 bytes
md5: 8648a37840b362eb860146627e8aac45
--
Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: DBI v2 - The Plan and How You Can Help
On Sat, 2005-07-09 at 12:42 +0200, Jochen Wiedmann wrote: Jonathan Leffler wrote: I dunno which DBMS support prepare without a database connection, but I would expect all the mainstream databases to require a database connection. +1 I'm also far from convinced that there's any significant benefit in separating the 'create a database handle' from the 'connect to database server' part. +1 Not to mention the effect, that one major charm of DBI is its simplicity: Connect, Execute for updates, inserts, or deletes and Connect, Execute, Fetch for select. I can't see an advantage in overly extending the interface. Personally I tend to agree with you. I haven't read the whole thread, but I'm not yet convinced that the DBI needs to change that much. Certainly the Sybase driver won't be able to support many of the proposed functionality, or won't benefit from the changes (i.e. no speed gain, no improved flexibility, etc). Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: Trouble connecting to Sybase 11x
On Wed, 2005-06-08 at 17:10, David Filion wrote: Hi, for the last 2 days I've been trying to get a simple connection to a Sybase 11x server running on Linux. Here is the script: There's a bug in the 1.05 version of DBD::Sybase when using Sybase 11.0.x. Please downgrade to DBD::Sybase 1.04. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: better error description
On Mon, 2005-05-16 at 08:58, Ing. Branislav Gerzo wrote: Hello all, exist a better error description for DBI errors? I have quite complex datastructure, I'm saving it to DB, using ODBC and MS SQL 2000. I get only: DBD::ODBC::st execute failed: [Microsoft][ODBC SQL Server Driver]Invalid charact er value for cast specification (SQL-22018)(DBD: st_execute/SQLExecute err=-1) a t ... line 291. That's a database server error - you need to look this up in the MS-SQL documentation and from there figure out what is wrong with your SQL. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: executing 2 and more statements
On Mon, 2005-05-16 at 15:22, Ing. Branislav Gerzo wrote:
Hello,
I'd like to do something like this:
$sth-prepare(...)
$sth-execute(...)
while (my $hr = $sth-fetchrow_hashref) {
my $oses = get_os( $hr-{id} );
...
}
Function get_os() prepare, execute and return $sth-fetchall_arrayref();
but I'm getting error:
DBD::ODBC::st execute failed: [Microsoft][ODBC SQL Server Driver]Connection
is b
usy with results for another hstmt (SQL-HY000)(DBD: st_execute/SQLExecute
err=-1
) at ...
is there some workaround for this, or I have to read all into memory ?
The work-around is to open a second connection to the server and use
that in the inner function. Be careful not to create a sequence of SQL
calls that causes a deadlock.
Michael
--
Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: DBD::Sybase make check errors
On Fri, 2005-05-13 at 15:27, Mark Vaughan wrote: All, I am receiving numerous errors when running the 'make check' for DBD::Sybase. My environment: Solaris 2.8 Perl 5.6.1 Freetds 0.63 Here is the output from 'make check': Running make test PERL_DL_NONLAZY=1 /usr/bin/perl -Iblib/arch -Iblib/lib -I/usr/local/lib/perl5/5.6.1/sun4-solaris -I/usr/local/lib/perl5/5.6.1 -e 'use Test::Harness qw(runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t t/autocommitok 1/5cs_config(CS_LOC_PROP) failed at /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 225. t/autocommitNOK 4 A) Have you done a google search for this error? B) Have you read the README.freetds file that comes with the DBD::Sybase distribution? The CS_LOC_PROP error is expected, and is benign. The other errors are also expected, because FreeTDS doesn't yet support all the features of Sybase's OpenClient libraries. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: Meaning of TYPE_NAME in type_info() output
On Fri, 2005-05-06 at 18:37, Avis, Ed wrote: If I make a user-defined type synonym, should the name of this synonym appear as TYPE_NAME in the type_info() output or should TYPE_NAME give the original SQL type the synonym is defined as? Currently if I make a user-defined type on Sybase and use it for some column C of a table T, then for 'SELECT C FROM T' DBD::Sybase gives me the name of the user type. I think I would prefer it to give the original SQL like 'varchar(10)' in the TYPE_NAME field, but I don't know what other DBDs do. Can you show me an example? I just tried it, using a user-defined type mapped to varchar(30), and type_info() returns char (which is correct). DBD::Sybase uses Sybase's sp_datatype_info catalog stored proc to get the datatype information - this is so that we return the same information that an ODBC or JDBC driver would get. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: Perl DBI - Bigint Issue
On Wed, 2005-05-04 at 19:16, Mohankumar wrote: Hi Folks, I am using the perl version 5.005_02 built for MSWin32-x86 and sybase 9.0.0. I have a DB and a table. I have used bigint as datatype for some columns in a table. The bigint values are stored correctly in database. While I trying to fetch the columns from the table, the columns which are having bigint datatypes (with values greater than 8-digits) are not fetched and it throws the below error. The bigint values with 8-digits or less canbe fetched displayed correctly. Please let me know the method to fetch the bigint values. DBD::ASAny::st fetchrow failed: Cannot convert 454 to a varchar (DBD: fetch failed) at c:\perl\test.pl line 28. Maybe not exactly what you want - but a workaround would be: select convert(varchar, the_bit_int_column) from as that moves the conversion from the client to the server. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: last_insert_id() / MSSQL
On Fri, 2005-04-29 at 15:08, Ing. Branislav Gerzo wrote: Hello all, I connect to MSSQL via ODBC, exist some method to get last inserted id? I read in DBI docs: For some drivers the value may only be available if placeholders have not been used (e.g., Sybase, MS SQL). In this case the value returned would be from the last non-placeholder insert statement. So I will to have using select max($field) from $table 'method' ? No - just do a select @@identity to get the latest value. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: Installing and trying DBD::Sybase 1.05
On Mon, 2005-04-11 at 10:16, Miguel Covas O'Ryan wrote: I've just downloaded DBD::Sybase 1.05 on my personal platform Mac OS X 10.3.8. I usually end up installing tested versions on HP-UX 11.x machines. I've been using DBD:.Sybase 1.04 plus DBI-1.48 with no problems (except those created by myself) on OS X. I've been able to generate the module, but the testing fails: $ make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/autocommitok 1/5dyld: /usr/bin/perl Undefined symbols: blib/arch/auto/DBD/Sybase/Sybase.bundle undefined reference to _CFBundleCopyBundleURL expected to be defined in a dynamic image blib/arch/auto/DBD/Sybase/Sybase.bundle undefined reference to _CFBundleGetBundleWithIdentifier expected to be defined in a dynamic image A little googling goes a long way... http://groups-beta.google.com/group/sybase.public.macosx/browse_thread/thread/58a37c62080397dd/d22a38db2705d421?q=_CFBundleCopyBundleURLrnum=2#d22a38db2705d421 Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: install_driver(Sybase) failed: DBD::Sybase initialize:
On Mon, 2005-04-11 at 14:58, Desai, Anand (HP-GDIC) wrote:
Help..
I have been struggling to get DBI to work on my server...
Here is the code..
#! /usr/bin/perl
#use strict;
BEGIN
{
$ENV{SYBASE} = /opt/sybase11.9.2;
}
nstall_driver(Sybase) failed: DBD::Sybase initialize: ct_init(1100)
failed at /opt/perl-uxpe/lib/5.8.0/PA-RISC1.1-thread-multi/DynaLoader.pm
line 249.
In general this means that the actual Sybase libraries that are loaded
are of an older version level than the ones used to build the
DBD::Sybase module. Another possibility is that your Sybase installation
is somehow incorrect.
The first thing to check is the SHLIB_PATH (I think that's what it's
called under HP-UX) to make sure that the correct Sybase library
directory is picked up at run-time, and second you should check that the
libraries in $SYBASE/lib are the right ones (for example, run
strings $SYBASE/lib/libct.a | grep Sybase
and see what version string you get.
As an example, I get:
Sybase Client-Library/15.0/A/DRV.15.0.0/Linux Intel/Linux
2.4.21-20.ELsmp i686/BUILD1500-032/OPT/Mon Feb 28 16:00:11 2005
In your case you should get 11.1.1 instead of the 15.0, and probably
some EBF string.
Michael
--
Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
DBD::Sybase 1.05_01
I've just uploaded DBD::Sybase 1.05_01 (a test/development version) to CPAN and to http://www.peppler.org/downloads/ This version fixes a number of problems with AutoCommit, and some additional small-ish issues. If you have the time please give this version a try. Thanks, Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
RE: string help!
On Thu, 2005-03-31 at 21:59, Anderson, James H (Company IT) wrote: I don't remember the details, but I think they're documented in DBD::Sybase. It believe it has something to do with the way sybase supports (cobbles up may be more appropriate) placeholders. Consequently, AFAIK, almost no one in the sybase world use them. That's not quite true. Placeholders in Sybase are well supported, with the notable exceptions that you can't use them for TEXT or IMAGE (i.e. BLOB) columns/parameters. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: Bug in $dbh-clone
On Thu, 2005-03-24 at 18:30, Tim Bunce wrote:
The 'bug' is that your driver is setting an attribute that's not valid.
The official attribute is called Username not User.
(But it's not really fair to call it a driver bug as many drivers
do that because they simply copied early drivers that did that.)
Indeed :-)
I'll fix it for the next release.
Michael
On Thu, Mar 24, 2005 at 11:55:04AM -0500, Anderson, James H (Company IT)
wrote:
DBI Version 1.42
Can't set DBI::db=HASH(0x8fd1834)-{User}: unrecognised attribute or
invalid value at //ms/dist/perl5/PROJ/DBI/1.42-5.8/lib/perl5/DBI.pm line
634, DATA chunk 1.
NOTICE: If received in error, please destroy and notify sender. Sender
does not waive confidentiality or privilege, and use is prohibited.
--
Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: Mixing select and print statements using DBI, DBD::Sybase
On Wed, 2005-02-09 at 21:07, David Goodman wrote:
Here is my simple, syntactically correct test case:
select ONE=1
print hello world!
select TWO=2
Using isql I get the results in the expected order:
ONE
---
1
(1 row affected)
hello world!
TWO
---
2
(1 row affected)
Using perl with DBI, DBD::Sybase the message hello
world! comes back first. I have permuted other print
and select statements and I find that my perl program
returns the messages first when the statements are run
in one batch. I find the same thing is true when my
perl program executes a stored procedure.
My program catches messages with an error handler
installed by setting the attribute
$dbconn-{dbhandle}-{syb_err_handler}. The rows are
retrieved using DBI call fetchall_arrayref.
Questions:
1. Can I get the results back in the expected order
when executing multiple statements from
perl/DBI/DBD::Sybase?
Theoretically yes - at least for queries (select statements). Print and
raiserror statements *should* normally be sent back in the same way as
you'd get them in isql, but you may be seeing buffering differences
where the error handler prints to STDERR and your data rows (from
fetchrow) are printed to STDOUT.
2. Can I suppress the result status of a stored
procedure from coming back as a row when using
fetchall_arrayref?
Yes, see the syb_doProcStatus attribute.
Michael
--
Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: Which driver for SQL Server?
On Tue, 2005-01-11 at 08:05, Daniel Kasak wrote: Michael Peppler wrote: The FreeTDS ODBC drivers support placeholders, IIRC. Are you *sure*? That's what I'm using at the moment ... DBD::Sybase with FreeTDS. DBD::Sybase with FreeTDS does NOT support placeholders (yet). But FreeTDS also includes an ODBC driver which DOES support placeholders - so you should be able to use DBD::ODBC with a driver manager of some sort and FreeTDS's ODBC libraries with placeholders. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: Which driver for SQL Server?
On Tue, 2005-01-11 at 04:06, Daniel Kasak wrote: Hi all. I'm after a driver for SQL Server. My requirements: - must run on Linux - must support placeholders - must work with SQL Server 7 That's it. To show I've researched a bit: I'm currently using DBD::Sybase with freetds, but this doesn't support placeholders. I had a quick look at DBD::ADO but it only runs on Win32. DBD::ODBC requires an ODBC manager, and I'm doing this on the cheap ( ie opensource only ) The FreeTDS ODBC drivers support placeholders, IIRC. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: DBD::ODBC, unixODBC, FreeTDS, MS-SQL, lazy DL, dbd_db_login/SQLSetConnectOption err=-2
On Wed, 2005-01-05 at 09:48, Honza Pazdziora wrote:
On Wed, Jan 05, 2005 at 08:55:26AM +0100, Cosimo Streppone wrote:
I have successfully used this combination:
- DBI :-)
- DBD::Sybase 1.04, compiled with $ENV{SYBASE}='/your/freetds/install'
- freetds 0.6x
The combination with DBD::Sybase used to work for me, but then in an
attempt to upgrade the server I managed to break the instalation and
now I get a handfull of cs_config(CS_LOC_PROP) failed
FreeTDS needs to handle a new situation, unfortunately as I've started
to set the locale in the context, rather than the connection. As this
functionality doesn't work with FreeTDS anyway you can simply comment
out the warning in the syb_init() call in dbdimp.c and rebuild.
Michael
--
Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
Re: DBD::Sybase::db do failed: Server message number=2762
On Thu, 2004-12-23 at 15:10, Anderson, James (Company IT) wrote: I googled and found a reference to this, but the link was dead :-( There no longer appears to be anything in the mail archive. DBD::Sybase::db do failed: Server message number=2762 severity=16 state=3 line=1 server=NYTIBA8 text=The 'CREATE TABLE' command is not allowed within a multi-statement transaction in the ... You can't create a table in a transaction, unless you have the ddl in tran option turned on for your database (which I *don't* recommend). Set AutoCommit=1 to solve this problem. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
ANNOUNCE: DBD::Sybase 1.05
I have just released DBD::Sybase 1.05 to CPAN and to
http://www.peppler.org/
This version fixes a number of subtle bugs, and includes a few slight
behavior changes - as usual it is recommended that you test your
applications/scripts with this new version before putting it into
production.
From the CHANGES file:
Release 1.05
BEHAVIOR CHANGE - $dbh-{LongReadLen} must now be called
before $dbh-prepare(). Previously you could call this after
the $dbh-prepare() but before the $sth-execute().
Install private statement handle methods for TEXT/IMAGE handling
to avoid $h-func() calls, and update documentation.
Implement experimental BLK API via prepare/execute loop.
Change default AutoCommit off mode from explicit transactions
to using the chained mode if it is available.
Add $sth-syb_describe() call, taken from Sybase::CTlib's
ct_describe().
Add ISO8601 date/time format for output.
Fix $sth-finish() behavior when syb_flush_finish is turned on.
Changed do { } while($sth-{syb_more_results}); idiom to use
redo instead.
Better/more consistent handling of multiple sth on a single dbh,
and new test file.
Bugs Fixed:
580 - Binding binary/varbinary values to placeholders sometimes
fails.
575 - Fails three tests under Tru-64.
577 - perl Makefile.PL fails if umask is 0.
578 - Better warning for calling $dbh-{LongReadLen} if $dbh is busy.
572 - Minor documentation update for bind_param().
Michael
--
Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer
Available for contract work - http://www.peppler.org/resume.html
DBD::Sybase 1.04_16 (1.05-TOBE)
All,
I've just uploaded DBD::Sybase 1.04_16 to CPAN (and to
http://www.peppler.org/downloads). I'm getting ready to release 1.05, so
I'd like to have this version tested as much as possible.
If you have the time and possibility please download/build/test in your
environment and report any problems to me.
Thanks!
Here's the CHANGES file for 1.05-tobe:
Release 1.05
BEHAVIOR CHANGE - $dbh-{LongReadLen} must now be called
before $dbh-prepare(). Previously you could call this after
the $dbh-prepare() but before the $sth-execute().
Install private statement handle methods for TEXT/IMAGE handling
to avoid $h-func() calls, and update documentation.
Implement experimental BLK API via prepare/execute loop.
Change default AutoCommit off mode from explicit transactions
to using the chained mode if it is available.
Add $sth-syb_describe() call, taken from Sybase::CTlib's
ct_describe().
Add ISO8601 date/time format for output.
Fix $sth-finish() behavior when syb_flush_finish is turned on.
Changed do { } while($sth-{syb_more_results}); idiom to use
redo instead.
Better/more consistent handling of multiple sth on a single dbh,
and new test file.
Bugs Fixed:
580 - Binding binary/varbinary values to placeholders sometimes
fails.
575 - Fails three tests under Tru-64.
577 - perl Makefile.PL fails if umask is 0.
578 - Better warning for calling $dbh-{LongReadLen} if $dbh is
busy.
572 - Minor documentation update for bind_param().
Michael
--
Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer
Available for contract work - http://www.peppler.org/resume.html
Re: Nested query problem
On Mon, 2004-12-13 at 15:51, Chuck Fox wrote: Michael A Chase tech wrote on 12/13/2004, 9:24 AM: On 12/13/2004 06:09 AM, Hardy Merrill said: I realize I'm splitting hairs here, and I'm no database expert, but I'm curious about your answer to this - wouldn't this be even slightly more efficient to write the WHERE clause conditions as most restricting first? In other words, SELECT feature.id FROM feature, reporter WHERE reporter.attributes_id = ? === most restrictive 1st AND feature.reporter_id = reporter.id === next most restrictive I was once told (or read?) that it is most efficient to put the most restrictive conditions first in the WHERE - is that right? I've always tended to put my joins towards the end of the WHERE when I have other criteria that I'm looking for - just curious to know if I've been doing it wrong. The general answer is that it all depends. A RDBMS builds its search plans based on a lot of factors; the order of the arguments may or may not be one of them. For instance, a long time ago in sybase it mattered. Now the actual order doesn't have that much influence. AFAIK the order has no influence at all. The order in which the tables are listed *can* have some influence, in particular if there are a lot of tables (6 or so) in the join, or if the forceplan option is on. In the latter case select ... from foo, bar where foo.id = bar.id . will fetch rows from foo first, and then do a nested iteration to fetch matching rows from bar. This is useful if we know that fetching rows from foo is expensive *and* we know that only a few rows will match. A typical use of forceplan is when one of the tables in the query is a proxy table (i.e. a table that is not located on the local server.) Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Available for contract work - http://www.peppler.org/resume.html
Re: documentation bugs on LongRealLen
On Fri, 2004-12-10 at 01:48, Bart Lateur wrote:
There's a few bugs in the code of the section of LongReadLen, even in
the latest version of DBI that is on CPAN. I quote:
If you can't be sure what value to use you could execute an
extra select statement to determine the longest value. For
example:
$dbh-{LongReadLen} = $dbh-selectrow_array{qq{
SELECT MAX(long_column_name) FROM table WHERE ...
});
$sth = $dbh-prepare(qq{
SELECT long_column_name, ... FROM table WHERE ...
});
Bug 1is a typo:
- $dbh-{LongReadLen} = $dbh-selectrow_array{qq{
+ $dbh-{LongReadLen} = $dbh-selectrow_array(qq{
Bug 2 is thinko. If your rows contain the values alpha, beta, zeta
omega in that column, $dbh-{LongReadLen} will be set to zeta. I
don't think that will buy us anything good. You want the *length* of the
*longest* string, not the string that sorts last in the word list. So,
somebody forgot about length(), or whatever the proper keyword is in
SQL.
Indeed. Sybase uses datalength() for this.
Michael
--
Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/
Sybase DBA/Developer
Available for contract work - http://www.peppler.org/resume.html
Re: Does DBD::Sybase support a way to get the number of rows affected by a statement?
On Thu, 2004-12-09 at 23:03, David Goodman wrote: I checked that DBD::Sybase documentation and did not find a way to get the number of rows affected by the previous statement. Is there an equivalent for ct_res_info()? Or is select @@rowcount the only way to do it? ct_res_info() (in C) will only return the number of rows returned by a SELECT after all the rows have been fetched. Same with SELECT @@rowcount (for obvious reasons - it's a bit hard to run SELECT @@rowcount *before* the SELECT data... :-) So DBD::Sybase's $sth-rows implementation will return valid data for SELECT statements right after the last row has been fetched. $sth-rows will return correct data immediately after execute() for INSERT/UPDATE/DELETE statements. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Available for contract work - http://www.peppler.org/resume.html
Re: DBIx::DBH - Perl extension for simplifying database connectio ns
On Wed, 2004-12-08 at 07:26, Jonathan Leffler wrote: Fundamentally, the DBI spec says: you connect to a database X by specifying 'dbi:X:whatever-X-chooses'. Trying to specify 'whatever-X-chooses' in some way that is independent of X is nonsense - and that's why the DBI spec does things the way it chooses to. I'm with Jonathan on this one. The DBI DSN spec is is what caused me to add all sorts of optional connection string parameters that are very specific to Sybase. These include things like setting the packet size, using SSL, setting the charset, etc. that happen prior to the actual connection being open. So even if you create a generic mechanism for building DSNs there will be a lot of stuff that won't work, or will need a whole host of exceptions and special handling. Michael -- Michael Peppler - [EMAIL PROTECTED] - http://www.peppler.org/ Sybase DBA/Developer Available for contract work - http://www.peppler.org/resume.html
Re: Problem with DBD::Sybase on Solaris machine
On Sun, 2004-12-05 at 00:29, Logan Capaldo wrote: Can't load '/usr/local/lib/perl5/site_perl/5.8.3/sun4-solaris/auto/DBD/Sybase/Sybase.so' for module DBD::Sybase: ld.so.1: /usr/local/bin/perl: fatal: relocation error: file /opt/syb12503/OCS-12_5/lib/libtcl.so: symbol comn_realloc: referenced symbol not found at /usr/local/lib/perl5/5.8.3/sun4-solaris/DynaLoader.pm line 229. Is the error I get. Has anyone had any experience with this? Any suggestions? Googling has not been terribly helpful. Hmmm - it's a classic error, so google *should* have found something. Anyway, the most likely problem is that you have LD_LIBRARY_PATH set, with the /usr/lib and/or /lib directories listed *before* the Sybase library directory. This causes ld.so to find /usr/lib/libintl.so instead of $SYBASE/$SYBASE_OCS/lib/libintl.so. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.peppler.org/ Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.peppler.org/resume.html
Re: DBD::ODBC and placeholders
On Sat, 2004-12-04 at 23:42, Brian Roy wrote:
Hello,
I was under the impression that placeholders would work in ODBC. I was
hoping this was the case as I don't want to rewrite my code that works
under mySQL. I'm trying to insert into MS SQL server with the same
statements. Please let me know if there is something I'm missing here.
sub sqinsert () {
my ($names, $formdata) = @_;
my $fields = join(', ', @$names);
my $places = join(', ', ('?') x @$names);
my $sql = INSERT into $table ($fields) values ($places);
$sth = $dbh-prepare($sql);
$sth-execute(@$formdata) || die $dbh-errstr;;
$sth-finish();
}
This is what I receive when I watch profiler on the SQL server. The
?'s get populated but they are with '@P's. I'm not sure how/why this
is happening.
INSERT into queue_stats (qdate, qtime, callid, queue, exten, qevent,
qholdtime, qcalltime, qorigposition) values (@P1, @P2, @P3, @P4, @P5,
@P6, @P7, @P8, @P9)
That's a parametrized language command. Normally the client app will
send this first, and then send each of the parameters that correspond to
the @Px parameters, and then execute the command. I don't really know
ODBC - have you tried turning on DBI-trace() to get more details on the
client side?
Michael
--
Michael Peppler Data Migrations, Inc.
[EMAIL PROTECTED] http://www.peppler.org/
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or
long term contract positions - http://www.peppler.org/resume.html
Re: DBIx::DBH - Perl extension for simplifying database connections
On Thu, 2004-12-02 at 08:53, Cosimo Streppone wrote: Tim Bunce wrote: I know what it does, I'm trying to find real examples that demonstrate why people think it's needed. Nick has provided a good one. Any others? Something like DBIx::DBH is in use in our organization. This is because every sql source (meaning database table) is accessed with standard objects and an external definition file like: For some db servers like Sybase, DB2 (MySQL?) a use dbname is needed after connection to properly select the database. DBD::Sybase will do the use for you if the database name is in the DSN. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.peppler.org/ Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.peppler.org/resume.html
Re: DBD::Sybase test errors (freetds-0.62.4)
On Mon, 2004-11-29 at 18:56, Jay Hannah wrote: It looks like DBD::Sybase is still working For certain values of working. (after forcing the install), but I thought I'd report these test failures. Seeing 86.84% okay is pretty scary. -grin- FreeTDS unfortunately does not yet implement the full Client Library API, so there are a number of things that don't work. Specifically things like RPCs (that's the ct_param() stuff you saw) and placeholders are known not to work (yet). Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.peppler.org/ Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.peppler.org/resume.html
RE: DBD::Sybase test errors (freetds-0.62.4)
On Mon, 2004-11-29 at 19:56, Jay Hannah wrote:
On Mon, 2004-11-29 at 18:56, Jay Hannah wrote:
It looks like DBD::Sybase is still working
For certain values of working.
Indeed. The story of my life. -grin-
FreeTDS unfortunately does not yet implement the full Client Library
API, so there are a number of things that don't work.
Specifically things like RPCs (that's the ct_param() stuff you saw) and
placeholders are known not to work (yet).
Roger that. Thanks.
Hypothetically*, would you have any interest in a patch to exec.t
(etc.) that would use Test::More and the SKIP blocks documented
therein to skip tests if $ENV{SYBASE} =~ /freetds/?
Sure.
Patches are always welcome!
Michael
--
Michael Peppler Data Migrations, Inc.
[EMAIL PROTECTED] http://www.peppler.org/
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or
long term contract positions - http://www.peppler.org/resume.html
RE: DBD::Sybase test errors (freetds-0.62.4)
On Mon, 2004-11-29 at 21:18, Jay Hannah wrote:
Hypothetically*, would you have any interest in a patch to exec.t
(etc.) that would use Test::More and the SKIP blocks documented
therein to skip tests if $ENV{SYBASE} =~ /freetds/?
Sure.
Patches are always welcome!
I asked because I'd be *changing* how exec.t (etc.) work -- to use
Test::More in all its glory instead of just printing to STDOUT...
That's fine. The newer .t files use Test::More - I've just not got
around to converting all of the tests to use it.
Michael
--
Michael Peppler Data Migrations, Inc.
[EMAIL PROTECTED] http://www.peppler.org/
Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or
long term contract positions - http://www.peppler.org/resume.html
Re: DBI installation/build troubleshooting resources
On Sun, 2004-11-28 at 08:26, Oliver Boermans wrote: Successfully installing the Perl DBI on OS X feels like a trial by fire. I have done it before but this time my feet are getting burnt! My attempts to install the perl DBI on my shiny new Mac have come to dead end. Problems (and solutions) with building DBD::mysql on OS X seem common - but I'm stuck on the prerequisite DBI module. (for a staging server for Movable Type). Rather than pasting in reams of terminal output here's a few key lines of one attempt to build. Boermans-Computer:~/.cpan/build/DBI-1.46 ollie$ perl Makefile.PL *** [...] Creating DBI::PurePerltest variant: t/zvpp_01basics.t Can't create t/zvpp_01basics.t: Permission denied at lib/DBI/DBD.pm line 3722. The most likely issue here is that the .cpan directory (and its children) is not owned by the user that is running the perl Makefile.PL. My *guess* is that you originally ran the CPAN utility as root using sudo. What happens there is that sudo doesn't switch the home directory information (HOME environment variable) to the home directory of the user you've switched to (root, in this instance). So now CPAN starts adding/building things in your home directory, but with ownership set to root. You can fix the ownership with: cd ~ sudo chown -R my_user_name .cpan where my_user_name is your login on that machine. Alternatively, run the perl Makefile.PL command above as root. Michael -- Michael Peppler Data Migrations, Inc. [EMAIL PROTECTED] http://www.peppler.org/ Sybase T-SQL/OpenClient/OpenServer/C/Perl developer available for short or long term contract positions - http://www.peppler.org/resume.html
