> from the FAQ for question 2.5) "I've moved the Sybase libraries..." > > - looks like you need to set both LD_LIBRARY_PATH > to the sybase/lib dir, And the SYBASE environmental > variable to the sybase dir (for it to find > the interfaces file). -- Adrian
Correct. LD_LIBRARY_PATH is only there to resolve loading .so libraries. The SYBASE environment variable must *always* be set so that OpenClient will find the interfaces file, and for the CTlib version that it will find the locale files as well. -Michael Peppler
> - the second part (Link the sybase libraries to > a standard dir) -- do we need to do an "ln -s" > on each file in sybase/lib to /usr/local/lib ? > can you "ln -s" sybase/lib to a subdir of /usr/local/lib > (my guess is no)... isn't totally clear from > FAQ write-up. > (I'm using sybperl-2.08 on solaris) - Adrian
Indeed, you need to link each of the Sybase libs (.so files) to /usr/local/lib (or /usr/lib). In csh syntax, that would be (run from the /usr/local/lib directory)
foreach i ($SYBASE/lib/*.so) ln -s $i . end- Michael Peppler
> > For folks using Sybperl with CGI, it looks like I need > to have the web server run as a certain user and put those > environmental variables in that user's .cshrc, unless > I can figure out how to do the second (linking libs to /usr/local/lib), > which I guess > would be more elegant. I'm thinking particularly about > folks who have different servers in production process (e.g. > dev -> qa -> staging -> production), where the hard-coding > of the dirs isn't so handy, and you can't do a build on > some of the machines (e.g. production). - AdrianThe *best* way to do things is to build sybp[erl so that the library path is coded into sybperl's .so files, and then make sure that the location of the Sybase libs is always the same on all of the machines that will need to run the scripts.
For example, if Sybase is always located in /usr/local/sybase then it becomes unnecessary to fool with LD_LIBRARY_PATH at all, which makes things a lot simpler. - Michael Peppler
Adrian's Followup: tried doing the linking thing, but couldn't really get it working. ended up using ln -s oldsybasedir newsybasedir . I think in future i may remake SybPerl with the path of the production Sybase open client libraries install and just have a soft link from that dir to my dir on my dev box. (In case you wanted to know, the differences of because of screwiness in filesystem setup, available disk space, etc.)
> Also, for the docs... do you recommend CTLib over DBLib or > vice-versa? -- it might be nice to have an analysis of differences > between the two somewhere... - AdrianThat write-up could probably be quite usefull... The functionality between the two is quasi identical, and the programming model is very similar. The main issue is really that Sybase has repeatedly stated that they will not enhance DBlib, and that support for it might be dropped at some point in the future.
So I think CTlib is probably the better choice. (although I've nearly only written DBlib apps myself - old habits die hard :-) - Michael Peppler
Adrian's follow-up: I've also ended up using the DBlib -- want to try CTlib at some point, trying to figure out how to do error-handling...
Adrian: i saw that, thanks, not sure how to call it... i'd think the dbnextrow or dbsqlexec or some such would return the error codes/objects that you'd pass to SybWWW.pm -- that's what i'm thinking of. i guess these are more the Sybase result codes... i'm thinking mainly of examples of people trapping those codes right in there. not sure if i'm being very clear :)...You have to be aware of the way Sybase handles errors, which is basically by sending you a message on a different channel.
The message handler gets called whenever the server detects an error. It's up to you to handle this correctly.
One way is to accumulate the error codes and the strings in a buffer, and check the buffer when one of dbsqlexec or dbresults returns FAIL.
The other (which I've nearly always used for my code) is to let the errors get printed somewhere (the screen or a log file) and simply check dbsqlexec and dbresults for FAIL, and in that case abort the operation (obviously).
The error will then be on the screen, or in a log file somewhere, potentially with the offending SQL code, which is quite practical.
See the discussion on the dberrhandle()/dbmsghandle() function descriptions on Sybase's documentation (available online at http://sybooks.sybase.com). - Michael Peppler
Adrian Scott wrote: > > i'm working on packaging up my sybperl install > to move to a production machine. > > i'm having trouble figuring out which sybperl files > i need to move and where they are. > > i have Sybperl made as a loadable module. > (Solaris 2.5.1) kiruna (3:48pm):2 > cd /opt/gnu/lib/perl5/site_perl/ kiruna (3:49pm):3 > find . -name Sybase ./sun4-solaris/auto/Sybase ./auto/Sybase ./Sybase kiruna (3:49pm):4 > And you want to add the files in [Sybperl source]/lib (like sybutil.pl, sybperl.pl etc...) which get placed into the site_perl directory. -Michael PepplerAdrian's follow-up comments: So it looks like the all of the following files in the site_perl subdirectory of your main perl directory.
I'm guessing that the .pl files in the site_perl directory itself are
optional, but I'm not sure, I think I'll include them just to be safe... :)
They are ctutil.pl, sql.pl, sybperl.pl and sybutil.pl.