Re: DBD::Sybase building Problem 64<>32bit

[Michael Peppler]

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  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
> 
> 



--
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

[Michael Peppler]

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 >

[Michael Peppler]

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."  -
> 
> Date: Fri, 19 Aug 2011 14:33:11 -0400
> From: "Mackin, Thomas E." 
> 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

[Michael Peppler]

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
 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 = < 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()

[Michael Peppler]

On Jun 3, 2011, at 9:58 PM,  
 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

[Michael Peppler]

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: Unicode and Sybase univarchar

[Michael Peppler]

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

[Michael Peppler]

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: using DBI for mutual exclusion across multiple servers

[Michael Peppler]

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

[Michael Peppler]

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,   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

[Michael Peppler]

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

[Michael Peppler]

ll=undef, uselongdouble=undef
  usemymalloc=n, 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

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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 ), 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

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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?

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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..

[Michael Peppler]

[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

[michael . peppler]

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?

[michael . peppler]

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

[michael . peppler]

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

[michael . peppler]

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

[michael . peppler]

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: temporary table "disapears"

[michael . peppler]

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
>
>
>   -

Re: Error installing DBD::Sybase on Solaris

[michael . peppler]

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,  line
44.

I am also having problem installing "Sybase Client Library API" ie.
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"

[michael . peppler]

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

[michael . peppler]

You can probably build freetds for this, but this will limit the 
functionality of DBD::Sybase as FreeTDS doesn't offer all the features of 
OpenClient (and is mostly tested against MS-SQL rather than Sybase ASE).

Michael




Internet
[EMAIL PROTECTED] - 30.04.2007 23:06
 

To: Michael PEPPLER
cc: dbi-users
Subject:Re: DBD::Sybase

[EMAIL PROTECTED] wrote:
>
> 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
>
>
>
>
>
> *E*xtranet
> [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

i'm surprised there is no other way, isn't there a freeTDS or something
else that will work instead?  Surely there must be others that use
DBD::Sybase on x86_64?







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

[michael . peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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

DBD::Sybase 1.07_06

[Michael Peppler]

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.
Added tds_keepalive DSN parameter.
Fixed incorrect handling of multiple result sets with DBI
1.53 and later.
Re-wrote $dbh->ping() in C for faster operation.
Allow automated build without prompts.
Fixed nsql() buglet.

Bug Fixes

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.

Thanks,

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

[michael . peppler]

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: ppms

[michael . peppler]

That's the most recent - AFAIK.

I don't know of any other source (and note that I don't build these myself 
- they have been contributed to me)

Michael




Extranet
[EMAIL PROTECTED] - 08.03.2007 03:36
 

To: dbi-users
cc: 
Subject:Re: ppms

On 3/7/07, Matthew Persico <[EMAIL PROTECTED]> wrote:
> Does anyone know of an up-to-date ppm repository for DBD-Sybase 1.07,
> Win32, activestae 5.8.8? I can't seem to make Google gurgle one up.
> Thanks.
>
Update: Is 
http://www.peppler.org/downloads/ActiveState/DBD-Sybase-1.07_01.zip
still legit with AS 5.8.8.820 (most recent) or should I keep
searching?

--
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: make test DBD::Sybase fails

[michael . peppler]

First of all you are using really old Sybase code - you can download 
current Sybase code from http://www.sybase.com/linux_promo.

Second, you didn't specify a database server to connect to, nor a user 
and/or password to use when connecting to that server, so DBD::Sybase will 
attempt to connect to a database server called "SYBASE" with the "sa" user 
and an empty password. That's almost certainly not correct, and that's 
most likely what fails in the tests.

Michael




Extranet
[EMAIL PROTECTED] - 05.01.2007 12:27
 

To: dbi-users
cc: 
Subject:make test DBD::Sybase fails

Hi friends!!

I've a trouble compiling the DBD::Sybase

I installed the following rpms:

sybase-common-11.9.2-3
sybase-doc-11.9.2-1
sybase-ase-11.9.2-3
sybase-openclient-11.1.1-3
sybase-monserver-11.9.2-3

and I  downloaded this archive: DBD-Sybase-1.07.tar.gz

perl Makefile.PL and make is OK
but make test fails.

Thanks in advance!!

perl Makefile.PL
Sybase OpenClient 11.1.1 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]:

Running in threaded mode - looking for _r libraries...
No thread-safe Sybase libraries found
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):
Sybase database to use on SYBASE (default: undef):

* Writing login information, including password, to file PWD.

Using DBI 1.40 (for perl 5.008005 on i386-linux-thread-multi)
installed in 
/usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/DBI
Writing Makefile for DBD::Sybase
[EMAIL PROTECTED] DBD-Sybase-1.07]# make
gcc -c  -I/opt/sybase-11.9.2/include -DNO_THREADS
-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.07\" -DXS_VERSION=\"1.07\" -fPIC
"-I/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE"   Sybase.c
gcc -c  -I/opt/sybase-11.9.2/include -DNO_THREADS
-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.07\" -DXS_VERSION=\"1.07\" -fPIC
"-I/usr/lib/perl5/5.8.5/i386-linux-thread-multi/CORE"   dbdimp.c
Running Mkbootstrap for DBD::Sybase ()
chmod 644 Sybase.bs
rm -f blib/arch/auto/DBD/Sybase/Sybase.so
gcc  -L/opt/sybase-11.9.2/lib -shared -L/usr/local/lib Sybase.o
dbdimp.o  -o blib/arch/auto/DBD/Sybase/Sybase.so
-L/opt/sybase-11.9.2/lib -lct -lcs -lsybtcl -lcomn -lintl -lblk -ldl
-lm
chmod 755 blib/arch/auto/DBD/Sybase/Sybase.so
cp Sybase.bs blib/arch/auto/DBD/Sybase/Sybase.bs
chmod 644 blib/arch/auto/DBD/Sybase/Sybase.bs
Manifying blib/man3/DBD::Sybase.3
[EMAIL PROTECTED] DBD-Sybase-1.07]# make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e"
"test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/autocommitdubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-9
Failed 8/9 tests, 11.11% okay
t/base..dubious
Test returned status 0 (wstat 11, 0xb)
t/exec..dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-22
Failed 21/22 tests, 4.55% okay
t/fail..dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-12
Failed 11/12 tests, 8.33% okay
t/login.dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-4
Failed 3/4 tests, 25.00% okay
t/main..dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-33
Failed 32/33 tests, 3.03% okay
t/multi_sth.dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-43
Failed 42/43 tests, 2.33% okay
t/nsql..dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-7
Failed 6/7 tests, 14.29% okay
t/place.dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-13
Failed 12/13 tests, 7.69% okay
t/threaddubious
Test returned status 0 (wstat 11, 0xb)
t/xblk..dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-62
Failed 61/62 tests, 1.61% okay
t/xblob.dubious
Test returned status 0 (wstat 11, 0xb)
DIED. FAILED tests 2-11
Failed 10/11 tests, 9.09% okay
Failed TestStat Wstat Total Fail  Failed  List of Failed
---
t/autocommit.t011 9   16 177.78%  2-9

Re: Error installing DBD::Sybase RPM

[michael . peppler]

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

[michael . peppler]

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

[michael . peppler]

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.
>>
>> 
>>   Start up a thread to handle the request, which sets a state
>> variable on
>> the statement handle then the request has been processed?
>> 
>
> 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

[michael . peppler]

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 "messag

Re: finishing sth using Childhandles

[michael . peppler]

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: finishing sth using Childhandles

[michael . peppler]

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: "max" datatypes support of SQL Server 2005 for DBD-ODBC

[michael . peppler]

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: "max" datatypes support of SQL Server 2005 for DBD-ODBC

[michael . peppler]

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: DBI-Sybase query returning weird characters

[michael . peppler]

DBD::Sybase does not handle character conversions - this is done at the
OpenClient level (i.e. FreeTDS in your case).

Make sure that the locale that is set for your two servers are the same,
and that the charset that is defined on the database server (run
sp_helpsort in a SQL command window).

Michael




Extranet
[EMAIL PROTECTED] - 09/08/2006 01:15

To:dbi-users

cc:


Subject:DBI-Sybase query returning weird characters


All -

I am running a Solaris server with freetds and the DBI-sybase to access a
Netcool database, which is based on Sybase. This is working great. I tried
installing the exact same setup on another server and am seeing some very
odd results when I try to return any integer values. Instead of numbers it
is returning weird characters (hearts, diamonds, nulls etc) ☺♦♦☻. I have
installed and re-installed DBI, DBD-Sybase and freetds with the exact
version that is running on my other server, but no luck. I can go into tsql
and run the exact same query as in my script and it returns the results
correctly. This leads me to believe it is a DBD-Sybase issue. I have also
ftp'ed my script over to my working server and it works fine there.

Server: Solaris 8
Perl: 5.8.3
freetds: 0.63
DBI: 1.47
DBD-Sybase: 1.05


The script:

#!/usr/bin/perl
print "starting\n";
use DBI;

$netcool = DBI->connect( 'dbi:Sybase:FIBERPRI', 'username', 'password', {
RaiseError=> 0, PrintError => 0, AutoCommit => 1 } ) or die "failed" .
$DBI::errst;;
if ($netcool) {
$select = $netcool->prepare(qq{select Severity from status where
Node like 'dls030'});
$select->execute;
while($sev = $select->fetchrow_array)
{
print "Severity: $sev\n";
}
} else {
print "FAILED";
}
print "end";


RESULTS:

cs_config(CS_LOC_PROP) failed at /usr/local/lib/perl5/5.8.3
/sun4-solaris/DynaLoader.pm line 249.
DBD::Sybase - can't get server version
Severity:
Severity:
Severity: ☻
Severity: ☻
Severity: ☻
Severity: ☻
Severity: ☺
Severity:
Severity:
Severity:
Severity:
Severity:
Severity: ☺
Severity:
Severity: ☻
Severity:
Severity:
Severity:
Severity:
Severity:
Severity:
Severity:
Severity: ☺
Severity:
Severity:
Severity:
Severity:
Severity:
Severity:
Severity: ☺
Severity: ☺
Severity: ☺
Severity:
Severity:
Severity:
Severity:
end

Note I get the cs_config error on my "good" server as well, doesn't seem to
effect it.

Any ideas would be appreciated.

Thanks,

-Ric






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

[Michael Peppler]

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: Problem with DBI

[michael . peppler]

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: DBD::Sybase misleads me?

[michael . peppler]

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 misleads me?

[michael . peppler]

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 question

[michael . peppler]

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

Re: DBD::Sybase question

[michael . peppler]

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

[michael . peppler]

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

[Michael Peppler]

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

[michael . peppler]

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

[Michael Peppler]

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

[michael . peppler]

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

Re: mod_perl2 DBI handle freshining problem solved "once and for all"...

[michael . peppler]

> > > 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

[michael . peppler]

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=st&q=dbd%3A%3Asybase+macosx&rnum=1&hl=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)
/usr/lib/gcc/powerpc-apple-darwin8/4.

Re: DBD::Sybase Stored Proc argument placeholders

[michael . peppler]

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)

[michael . peppler]

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)

[Michael Peppler]

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"

[michael . peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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

[michael . peppler]

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

[Michael Peppler]

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

RE: [dbi] DBD::Oracle, Instantclient and HP-UX...

[michael . peppler]

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: [dbi] DBD::Oracle, Instantclient and HP-UX...

[michael . peppler]

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.

DBD::Oracle, Instantclient and HP-UX...

[michael . peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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: executing 2 and more statements

[Michael Peppler]

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: better error description

[Michael Peppler]

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: DBD::Sybase make check errors

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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: install_driver(Sybase) failed: DBD::Sybase initialize:

[Michael Peppler]

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

Re: Installing and trying DBD::Sybase 1.05

[Michael Peppler]

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=_CFBundleCopyBundleURL&rnum=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

DBD::Sybase 1.05_01

[Michael Peppler]

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!

[Michael Peppler]

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

[Michael Peppler]

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,  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

[Michael Peppler]

On Thu, 2005-02-10 at 19:31, Chuck Fox wrote:
> Just spoke to my Sybase Tech Support engineer and she assures me that
> the statements should be coming in the order specified by the SQL. 
> She suggested that the DBD::Sybase implementation may be at the heart
> of the matter. 
> 

I'll take a look at it - but as I don't really do anything fancy with
error handlers in the code I would expect this to work the same way as
isql.

Ping me again in a few days if you haven't heard from me on this.

Michael
-- 
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

[Michael Peppler]

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?

[Michael Peppler]

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?

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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)

[Michael Peppler]

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

[Michael Peppler]

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

[Michael Peppler]

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?

[Michael Peppler]

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

[Michael Peppler]

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