I have compiled dbd-sybase module(1.07) to add it to my perl(5.12.3) on windows. However, when I trying to use it using following script:
use DBI;
DBD::Sybase;
$ENV{SYBASE} = 'E:\Sybase';
$ENV{SYBASE_OCS} = 'OCS-15_0';
$ENV{SYBASE_ASE} = 'ASE-15_0';
$SERVER="ABC";
$DATABASE="dadw";
$USER_NAME="";
$PASSWORD="";
$dbh = DBI->connect("dbi:Sybase:server=$SERVER;databse=$DATABASE",$USER_NAME, $PASSWORD);
I am getting following error message:
install_driver(Sybase) failed: DBD::Sybase initialize: cs_ctx_alloc(113) failed
at c:/perl/lib/DynaLoader.pm line 223.
Compilation failed in require at (eval 4) line 3.
at b.pl line 11
Can someone help in solving this error message.
It appears that the driver is using CT-Connect libraries, so I would guess it needs to have valid server information in the interfaces file.
On windows the file is usually located in C:/sybase/interfaces.ini
Check this answer for more details on creating interface file entries.
Using Sybase ASE BCP to a Remote Server
In Sybase, the interfaces file in Windows is called sql.ini and it is located in the c:Sybase/ini/ folder.
Related
I checked the log file and I think this is the part that caused the problem:
Setting up database
[15:30:54] Configuring pg11 to point to existing data dir D:\John's Files\My Documents\Code\Databases\PostgreSQL\data\pg11
Setting PostgreSQL port
= 5432
Executing C:\Installed Software\Developer Software\PostgreSQLv11.1/pgc config pg11 --datadir "D:\John's Files\My Documents\Code\Databases\PostgreSQL\data\pg11"
Script exit code: 1
Script output: ################################################
# FATAL SQL Error in check_release
# SQL Message = near "s": syntax error
# SQL Statement = SELECT r.component FROM releases r, versions v
WHERE r.component = v.component
AND r.component LIKE '%D:\John's Files\My Documents\Code\Databases\PostgreSQL\data\pg11%' AND v.is_current = 1
################################################
Script stderr: Program ended with an error exit code
Error with configuration or permissions. Please see log file for more information.
Problem running post-install step. Installation may not complete correctly
Error with configuration or permissions. Please see log file for more information.
I think the problem is the apostrophe in "John's". Does anyone know if that's right? Is there a fix to this problem? I don't want to rename my directory because Postgresql can't handle apostrophes.
I am trying to connect to access 2007 database using perl. Below is the code that I tried executing
use DBI;
$path='T:\a\abc.accdb';
$datasource = "driver={Microsoft Access Driver (*.mdb,*.accdb)};DBQ=$path";
$dbh = DBI->connect("dbi:ODBC:$datasource", '', '') || die "Error connecting: $!";
$query="select name from receiver";
$exe=$dbh->prepare($query) or die "cannot prepare";
$exe->execute or die "cannot execute";
$a=$exe->fetchall_arrayref();
foreach $aa(#{$a})
{
print #$aa;
}
but the execution fails with the below error
DBI connect('driver={Microsoft Access Driver(*.mdb,*.accdb)};DBQ=T:\a\abc.accdb','',...)failed: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified (SQL-IM002) at test.pl line 5.
Error connecting: at test.pl line 5.
can someone please guide me how to resolve this issue.
Your driver name is missing a space. ODBC is very fussy about that. Try
$datasource = "Driver={Microsoft Access Driver (*.mdb, *.accdb)};DBQ=$path";
Also, NAME is a reserved word in Access SQL so you may need to use
$query="select [name] from receiver";
My experience with DBI:ODBC is somewhat dated but I would suggest the following:
Check the driver names in the ODBC datasource setup and make sure
that you have the spelling right. (spaces and all) - Maybe set up a
DSN and use that instead - more reliable
Check that the file exists (I don't think that is the problem from
the error message)
Capitalization on the Driver/Dbq (not likely but we are dealing with
MS)
I was using this piece of php script in a application running under over XAMPP on my local machine:
$dom = new DomDocument();
$filename = "library.xml";
if (!$dom->load($filename))
die("Could not parse iTunes XML file: ".$filename);
Then i tried to move this application to a WampServer without success, with the following warning:
Warning: DOMDocument::load() [domdocument.load]: I/O warning : failed to load external entity "file:///C:/wamp/www/parser/library.xml" in C:\wamp\www\parser\includes\libs\itunes_xml_parser.lib.php on line 111
This line in the error is exactly the load line, which worked flawlessly in earlier versions of XAMPP and isn't working now on XAMPP 1.7.7
As per this why don't you try using an absolute path for your filepath.
Also i see that this php file is located at C:\wamp\www\parser\includes\libs and library.xml is being searched at C:/wamp/www/parser/. Is this correct?
It could also be possible that you had turned off warnings/errors in your earlier xampp installation.So check this also.
I'm having somewhat weird problem with DBD::Informix. If I run a simple script like that:
use DBI;
my $dbh = DBI->connect_cached('dbi:Informix:database', '', '');
my $sth = $dbh->prepare('select foo from bar');
...
It works all right. But if I try to do exactly the same from a test script it fails with the following message:
SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument
The only difference I see is that test script is quite heavy on module usage; it is based on Test::More and loads a lot of submodules that are to be tested.
Turning on DBI trace does not provide anything useful (for me, at least). Simple script runs along just fine:
DBI 1.616-nothread default trace level set to 0x0/1 (pid 9685 pi 0) at test_ifx.pl line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect(dbi:Informix:cms#cms_ol, , ****, HASH(0x13fad0))
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9685 ruid=106 euid=106
install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0x1c8070)
!! warn: 0 CLEARED by call to connect method
-->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms#cms_ol' - no user info
-->> DBD::Informix::dbd_ix_db_check_for_autocommit()
... and the only difference in trace of the problematic script I see is that it just fails:
DBI 1.616-nothread default trace level set to 0x0/1 (pid 9687 pi 0) at 22_report.t line 5 via 22_report.t line 6
Note: perl is running without the recommended perl -w option
-> DBI->connect_cached(dbi:Informix:cms, , ****)
-> DBI->install_driver(Informix) for solaris perl=5.008009 pid=9687 ruid=106 euid=106
install_driver: DBD::Informix version 2011.0612 loaded from /cms/webdash/lib/arch/DBD/Informix.pm
<- install_driver= DBI::dr=HASH(0xb619bc)
!! warn: 0 CLEARED by call to connect_cached method
-->> DBD::Informix::dbd_ix_db_connect()
CONNECT TO 'cms' - no user info
***ERROR***
SQL: -25588: The appl process cannot connect to the database server cms_ol.
ISAM: 22: Invalid argument
<<-- dbd_ix_db_connect (**ERROR-1**)
<<-- DBD::Informix::dbd_ix_db_connect()
I'm running custom Perl 5.8.9 build in Solaris 9, with latest DBI and DBD::Informix versions, against Informix IDS 9.40UC.
Update: If I try to be a smartass and put a block like that at the top of the heavy test script:
use DBI;
BEGIN { my $dbh = DBI->connect_cached( ... ); print "Connected!\n" if $dbh; }
... it prints like this:
Connected!
Out of memory!
Callback called exit.
END failed--call queue aborted at t/22_report.t line 20.
Callback called exit at t/22_report.t line 20.
BEGIN failed--compilation aborted at t/22_report.t line 24.
My guess is that DBD::Informix conflicts with some of the modules loaded after the connection is made. But which one? That's the question...
Another update: It appears that the above trick does something unwieldy. I tried to load all the modules explicitly by replacing 'use Module' with 'require Module; Module->import'. Pure Perl modules are OK but whenever XS module using XSLoader appears, Perl goes boom with friendly 'Out of memory' message. And if I move Informix connection below module initialization, it works all right - except DBD::Informix fails with the same -25588 error. Boomer. I'm at loss. :(
Another another update: I tried to run the same script with standard Perl 5.6.1 shipped with Solaris 9, using DBI 1.601 (the latest that would compile with Perl 5.6) and DBD::Informix 2011.0612. Same thing, so it's not custom Perl giving me trouble.
I can also add that the test module in question was prototyped using DBD::SQLite and fully works. It is the final test with DBD::Informix that is failing... As usual. :/
Workaround: following e-mail discussion with Jonathan, a workaround was found: addition of streams-based 'onipcstr' connection to Informix server allowed DBD::Informix to connect. Apparently, some XS modules interfere with default shmem-based connection method, although the culprit is unknown at the moment.
Further discussion
Custom-built Perl is, in my experience, easier than the system Perl. I never modify the system's Perl installation (I don't want to break it) so I always build my own.
You appear to have:
Solaris 9 (SPARC?)
Perl 5.8.9
DBI 1.616
DBD::Informix 2011.0612
ESQL/C (CSDK) 2.81
Informix Dynamic Server 9.40
We don't have the detailed sub-version of ESQL/C and IDS (2.81.UC2, 9.40.UC5, or whatever). There's a hint that you are using a 32-bit version of IDS, so probably everything is 32-bit. You are probably aware that 9.40 is no longer supported by IBM (and, indeed, its successor version 10.00 is also out of support). However, superficially, none of that should matter very much. The failing t91lvarchar.t is not a big issue.
Can you run the connect in working and non-working modes with DBI_TRACE=9 set in the environment.
If the trace for the connect operation is too voluminous to go into an update to the question, we'd better take this off-line to the DBD::Informix support channels (that's me, but by email).
The 'ISAM' error of 22 (Invalid argument) is puzzling. I'm curious about what is in your sqlhosts file for this server - the entry for cms_ol specifically. I'm not sure it will reveal anything, not least because you say the sample ESQL/C below (in the 'First hypothesis' section) works OK, and sometimes the Perl connects and sometimes it does not.
I wonder if there is a name conflict somewhere between functions in the shared libraries? That sort of thing will be hell to track.
First hypothesis
Further information received shows that this was not the crucial distinction.
The difference appears to be:
Works: CONNECT TO 'cms#cms_ol' - no user info
Fails: CONNECT TO 'cms' - no user info
The tricky part to explain is why the second fails, especially as the error goes on to mention cms_ol.
The workaround is to specify the server name in the connect string:
DBI->connect(dbi:Informix:cms#cms_ol, , ****, HASH(0x13fad0))
DBI->connect_cached(dbi:Informix:cms, , ****)
The underlying problem is more likely at the ESQL/C level than anything to do with other Perl modules. That is, if you compiled and executed this ESQL/C program, it would fail on cms and work on cms#cms_ol:
int main(int argc, char **argv)
{
$ char *dbs = "cms";
if (argc > 1)
dbs = argv[1];
$ whenever error stop;
$ connect to :dbs;
return 0;
}
You could run it without an explicit database name (or with an explicit 'cms'), and I would expect it to fail. You could run it with 'cms#cms_ol' and I would expect it to pass. The program will say nothing if it passes; it will be obvious when it fails (though the messages will not be beautiful).
There is an outside chance it is something to do with connect_cached; that is a service provided by the DBI module and not by the DBD::Informix module. On the whole though, it is more likely something happening at the ESQL/C level.
Issue: Perl script works fine in command prompt, but fails on ODBC as a CGI script
Settings:
Win XP Pro 64 bit version 2003 SP2
Apache 2.2.17 Win32
Active Perl 5.12.2 (not Perl64)
an ODBC DSN is created for SQL SERVER
Details: from command prompt, Phone.pl runs OK - it gets query results as expected - which means DBI works fine
as a CGI script, Phone.pl prints HTML as expected before ODBC init code. (Apache settings work OK for non-ODBC script.)
here's the msg in error.log of Apache
[Tue Nov 23 13:27:57 2010] [error] [client 127.0.0.1] DBI connect('SQLSVR206','administrator',...) failed: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified (SQL-IM002) at C:/CGI/Phone.pl line 32
Any idea why it behaves differently?
#!c:/perl/bin/perl.exe
use CGI qw(:standard);
use strict;
use warnings;
use DBI;
my ($sqlstr, $sql_UNITED, $dbh206);
# 206
# select * from getProvFINON('270762789')#TIN
my #colUNITED = qw/ADR_LN_1_TXT PROV_SYS_ID ZIP_CD FULL_NM SOURCE PROV_TIN BILL_TEL/;
sub Init(){
$dbh206 = DBI->connect ("dbi:ODBC:SQLSVR206",'USER','PASSWORD',{RaiseError=>1})
or die $DBI::errstr;
$sqlstr = qq/ select * from getProvFINON(?) /; #parameters TIN
$sql_UNITED = $dbh206->prepare($sqlstr)
or die "prepare failed: " . $dbh206->errstr();
}
sub test1{
my $tin = shift();
$sql_UNITED->execute($tin) or die $sql_UNITED->errstr;
my $row = $sql_UNITED->fetchrow_hashref;
while(defined ($row)){
foreach(#colUNITED){
print $row->{$_}."~~~";
}
print "<p>";
$row = $sql_UNITED->fetchrow_hashref;
}
}
print header;
print "test text<p>";
Init();
test1('270762789');
print "999999999999<p>";
==========================================================
UPDATE: part of the problem is the 32-bit VS 64-bit ODBC issue
see http://support.microsoft.com/kb/942976
HOWEVER, after I set up ODBC, I still got following error in Apache log
[Wed Nov 24 01:38:48 2010] [error] [client 127.0.0.1] DBI connect('SQLSVR206-32','',...) failed: [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user 'MYDOMAIN\GARY$'. (SQL-28000) at C:/CGI/test.pl line 15
I logged in as MYDOMAIN\administrator and started Apache.
ODBC was set up to use "With Windows NT authentication using the network login ID" Where does this "MYDOMAIN\GARY$" come from? Thanks!
==========================================================
FINAL UPDATE: Apache services runs using "Local System account", and that's where the "MYDOMAIN\GARY$" comes from. The thing is GARY is not with the company and his ID has been dropped from SQL Server, but ODBC code in CGI inherited GARY from Apache, resulting in error 28000.
So the problem was a convolution of
1) 32/64 bit ODBC DSN and
2) default account used by Apache
Maybe the ODBC datasource is listed under 'User DSN' and not 'System DSN'. I think that the identity that your web server runs as only has access to System DSN.
In case my post doesn't make sense, I'm editing it in order to add a link to information about the difference between User vs. System DSN's: http://www.truthsolutions.com/sql/odbc/creating_a_new_odbc_dsn.htm
Something is up with Windows 7 ODBC connections that I can't figure out either. I'd set up the ODBC and it would test fine but get a similar error as you show. Even connecting MS SQL Server Mgmt Studio to some SQL servers I have to explicitly put in extra connection settings. Since I only have the issue on some SQL servers (which I don't own) I think it's a server side problem.
On PERL i finally gave up and just created the DSN file with said extra connection settings and pointed to it directly. Note how the server name is there twice.
use DBI;
use SQL::Abstract;
my $CONNECT = "FILEDSN=thefile.dsn";
my $dbh = DBI->connect("dbi:ODBC:$CONNECT", "myidsid", "passwordThatsNotUsed");
with the ODBC file looking something like:
[ODBC]
DRIVER=SQL Server Native Client 10.0
UID=myidsid
Address=servername,3180
Network=DBMSSOCN
APP=Microsoft® Windows® Operating System
Trusted_Connection=Yes
SERVER=servername
PWD=someTextInPlaceOfPasswordAsItsNotUsed