Re: seg fault unixODBC
Matthew Bartholomew wrote: Not sure what to do from here...any advice would be great. Thanks... -Matt [root@ns3 root]# isql -v Segmentation fault [root@ns3 build]# isql -b Segmentation fault [root@ns3 build]# isql -c Segmentation fault [root@ns3 build]# isql -w Segmentation fault [root@ns3 build]# isql -mn Segmentation fault .you get the idea...isql seg faults on most every command. --version is the only one that doesn't seg fault. I upgrade to unixODBC 2.2.2 in hopes of fixing this, but no avail. Hi, Try isql -v wibble You should get a DSN not found error. If you still get a seg fault, try running under GDB and see what happens. If you can connect to postgres and not freetds, I would ask on the freetds lists as its probably a freetds issue. If you can't connect to postgres, and still get the segfault, ask me as its a unixODBC problem. I would guess its not DBI, so I will send this the those lists (just so they know its been answered), but you may as well trim any other answer to a smaller number of lists. -- Nick Gorham Easysoft Limited http://www.easysoft.com
Re: :ODBC SQL Server problem
Jeff Urlwin wrote: Using the latest DBI and DBD::ODBC to connect to SQL Server I'm getting this error... Connection is busy with results for another hstmt (SQL-S1000)(DBD: st_execute/SQLExecute err=-1) This happens when I use the same database handle to execute two different statements. When I open two different connections, this problem does not exist. It must be some sort of a DBD::ODBC or ODBC config, since using OLEDB, this also is not an issue. Yes, this is a known issue and one caused by the driver itself. Sybase also seems to have (or used to have) this limitation. FYI, its the same for both SQL Server and Sybase. The TDS protocol that communicates with the server (which both use) causes the limitation. Any workaround operates by causing TDS to only return one row per fetch, by default; after the select the entire result set is pushed down the wire, so its not possible to have two concurrent result sets. Nick.
Re: :ODBC bug?
Dave Thorn wrote: This is where my knowledge goes a bit flakey. It works in MS Query Analyzer, which, according to someone here, isn't using ODBC. Are you certain of that, last time I looked, it did use ODBC. -- Nick Gorham Easysoft Limited http://www.easysoft.com
Re: :ODBC bug?
Dave Thorn wrote: On Tue, Oct 22, 2002 at 11:48:01AM -0400, Jeff Urlwin wrote: Unfortunately, that's not readable. I only see the one row. Well, it shows RICHARD G. MITCHELL for PERFORMER, and nothing for DURATION, using the same queries as posted in code earlier. Just to warn you, isql doesn't check if the field is null, it just calls SQLGetData as a SQL_CHAR, and prints the char that comes back. -- Nick Gorham Easysoft Limited http://www.easysoft.com
Re: DBD-ODBC core dumps (atexit)
Darren Edgerton wrote: Hi Jeff, i tried .45_18 but still get the same results IF you are using unixODBC and DB2, you need to add DontDLClose = 1 to the driver entry in odbcinst.ini, The db2 driver uses atexit() to register a exit function, and if the DM unloads the lib before exit, its still called, but is nolonger in the process address space, with the effect you see. If you are not using unixODBC, please ignore the above :-) -- Nick Gorham Easysoft Limited http://www.easysoft.com
Re: Driver Manager required for DBD:ODBC
Levine, Peter W wrote: Hi, The web page for Easysoft's ODBC-ODBC brige states that no client side driver manager is required. It states that unixODBC is available for a driver manager if that is desired. However I thought that DBD:ODBC required a driver manager? Pete Peter Levine [EMAIL PROTECTED] (415) 286-5716 May be a case of the docs not matching current reality. When the bridge was started there was no reliable open odbc 3 DM about, so the bridge was designed to mimic a driver manager. Now unixODBC is there its not required (though it still can) to do the extra functions. However since then DBD::ODBC has now stated that it required a driver manager (for good reason IMHO, though I am biased :-). So all the above statements are true to a extent. -- Nick Gorham Easysoft Limited
Re: bogus warnings while making DBD-ODBC-0.43
Jeff Urlwin wrote: Peter, I've never seen the multiple copies message before, but as long as you only have one :) #2 is just an informational message. However, unrelated to that: Make sure you get unixODBC version 2.2.3. Just so you know, 2.2.3 is not released at the moment, there is a snapshot on ftp://ftp.easysoft.com/pub/beta/unixODBC and people are welcome to try it, but it will change before its official. -- Nick Gorham Easysoft Limited http://www.easysoft.com
Re: Connecting MS SQL 2000 w/ DBD::ODBC
Jeff Urlwin wrote:
That is an issue with the database itself. I believe there may be a
workaround (check the archives). There is a hack which may allow this for
you. Here's the text of the patch (from the DBD::ODBC pod documentation).
SQL_ROWSET_SIZE attribute patch from Andrew Brown
There are only 2 additional lines allowing for the setting of
SQL_ROWSET_SIZE as db handle option.
The purpose to my madness is simple. SqlServer (7 anyway) by default
supports only one select statement at once (using std ODBC cursors).
According to the SqlServer documentation you can alter the default setting
of
three values to force the use of server cursors - in which case multiple
selects are possible.
The code change allows for:
$dbh-{odbc_SQL_ROWSET_SIZE} = 2;# Any value 1
For this very purpose.
The setting of SQL_ROWSET_SIZE only affects the extended fetch command as
far as I can work out and thus setting this option shouldn't affect
DBD::ODBC operations directly in any way.
As always -- your mileage may vary...
Jeff
Be warned, you may get away with it, but you *can* put your server in a
spin-lock doing this if you don't retrieve all the data from each row for each
fetch.
--
Nick Gorham
Easysoft Ltd
Re: Connecting MS SQL 2000 w/ DBD::ODBC
Stefan Mueller wrote: Hello, Nick Gorham wrote: Be warned, you may get away with it, but you *can* put your server in a spin-lock doing this if you don't retrieve all the data from each row for each fetch. Have you got an infinite loop when you don't retrieve all data? Shouldn't you get an error message? You should but you don't. I am talking about Microsofts ODBC driver here. -- Nick Gorham Easysoft Ltd
Re: HELP! production server down
Turn on tracing in the driver manager in odbcinst.ini [ODBC] Trace=Yes TraceFile=/tmp/sql.log Have a look to see whats being passed to SQLDriverConnect and SQLConnect, you may need a DSN= in front of the connect string. Tim Harsch wrote: Hi all, I was upgrading my DBD::ODBC from 0.28 to 0.38. The tests seemed fine. But after make install none of my scripts can connect anymore. I get this error: [root@perseus installs]# testODBC.pl DBI-connect(HOMER;DBN=devel) failed: [unixODBC][Driver Manager]Data source name not found, and no default driver specified (SQL-IM002) [unixODBC][Driver Manager]Data source name not found, and no default driver specified (SQL-IM002)(DBD: db_login/SQLConnect err=-1) at ./testODBC.pl line 8 My setup: Redhat Linux 7.0 DBI 1.21 DBD::ODBC 0.38 EasySoft ODBC::ODBC bridge software perl 5.6 SQL Server 2000 Please help! __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com
Re: PERL MODULE DBD::ODBC
YOUNG,ALEX (Non-HP-UnitedKingdom,ex2) wrote: Hi all, I am having a problem installing the above module (Version 0.32). I have succeeded in the past with a statically linked version but cannot get the dynamic one going. The driver I'm using is Redbrick (a data warehouse now provided by Informix (IBM)). The only tweak that I have made is a symbolic link from the rbsql*.h files provided with Redbrick to the required sql*.h files. There was someone a couple of days ago using just this driver. Is it on Linux ? if so it may be better to install to a ODBC Driver manager first. Nick
Re: Mutiple ODBC APIs?
drewhead wrote: Well, if you have DBD-ODBC working I would expect the same ini settings could be used to get it working under a driver manager. Just what made you think it wouldn't work ? -- Nick Gorham Easysoft Ltd You mean initially the way I set it up incorrectly? I didn't know enough about what I was doing to make the distinction between a manager and a driver. You and others in the thread have given me that education, thanks. Moving forward I do not have DBD-ODBC working correctly with a manager... yet. Given that I have DBD-ODBC using a driver in use, how do I compile/intsall/test DBD-ODBC with a manager plugging in my driver which no one yet has confirmed will work without showing my users any noticiable downtime. I'm not a particularly fast typer. :) I guess it's fair to say I have a healty fear of putting unknowns into production. This also really gets beyond the scope of the list (sorry folks). I think I'll just build another perl install for testing. -- Drew Sure, if its working don't break it, but if you do need other connections it will probably work out simpler to use a driver manager in the long run. -- Nick Gorham Easysoft Ltd
Re: Mutiple ODBC APIs?
Nick Gorham wrote: drewhead wrote: Yes Oliver, this is my understanding of the issue. As long as we're talking specfics, this is a ODBC API for RedBrick, an IBM product formerly Informix (no DBD-Infomix isn't for the DBMS). I actually did try iODBC first, but was unsuccessful. Upon asking on the RedBrick list I was contacted by a helpful user who showed me how it could be done linking some of the libs (that have an extra 'rb' in their name). Alas, I've now coded myself into a corner needing access to other drivers that this 'interface' can't handle. If the solution here is to compile what I currently have working with RB to a diffrent name, perhaps RBODBC, I'll certianly give that a shot. I don't think I've ever changed a module's name. Is there anything to be aware of besides wholesale %s/ODBC/RBODBC/g? -- Can someone point me to where I can get a copy of this driver and a database to connect to and I will see why there are problems with driver managers. -- Nick Gorham Easysoft Ltd Ok, I downloaded a copy of informix-se and the client libs, it was a bit of a hack, but it seems to work under unixODBC ok. The driver does its own thing about ini files, so what I did was link the user dsn (/root/.odbc.ini in this case) which is what the driver was looking in to the system dsn one. However you could just use a user dsn. The odbcinst.ini entry is [INFORMIX] Driver = /opt/informix/lib/cli/libifcli.so FileUsage = 1 the odbc.ini entry [Infdrv33] Driver=Informix Description=INFORMIX 3.3 32-BIT Database=/opt/informix/bin/stores7 Servername=demo_se CursorBehavior=0 CLIENT_LOCALE=en_us.8859-1 DB_LOCALE=en_us.8859-1 TRANSLATIONDLL=/opt/informix/lib/esql/igo4a304.so It connects with the DBD:ODBC make test, but fails as it doesn't seem to support any long types (well looking at the output from SQLGetTypeInfo it doesn't) -- Nick Gorham Easysoft Ltd
Re: Mutiple ODBC APIs?
Simon Oliver wrote: I raised this issue with the SAP DB driver (it does a simillar thing apparently). I've had no response from the SAP DB people as yet. IMHO, compiling DBD::ODBC against a proprietry interface should not be allowed without a name change to the module. This may sound a bit harsh, but isn't a proprietary ODBC interface a contradiction ? Wouldn't it be better to get the interface working behind a driver manager (Ok I am biased on that one), the DM could well help make it more of a standard ODBC interface then. Nick Gorham
Re: Fw: RE: MS Access file - accessing from Linux?
About-tw.com §K¶O¤H¤O»È¦æ wrote: You should use the openlink sdk connect to windows.Use the Multi-tie version of oprnlink software and SDK. Download the l3br.taz ,l3ko.taz ,l3kuz.taz ,l3oc.taz and install.sh for linux.And remeber setup the $ENV before you make. Download the ntbr.zip for windows. On windows,you should install the MSDE to transfer the access(*.mdb) to MS-SQL .Then configure the ODBC DSN . I just do it by this way. But the problem is I can't directly connect to the access database via DBD-ODBC from linux .It need to transfer to MS-SQL style. Hope this will help you a little bit. If you find out the other way to connect access database, please let me know. Regards, Tom Wu [EMAIL PROTECTED] As someone else has mentioned a commercial solution our (Easysoft) ODBC-ODBC bridge will allow you to connect to the access ODBC driver and from there to the ..mdb. This does require the mdb to be on a windows box, no one has a full spec for the mdb files, so a direct driver is not possible at the moment. -- Nick Gorham Easysoft Ltd
Re: Lotus Notes
Adam Gomes wrote: Anyone happen to know of anyone who might have put together a module or a DBD for Lotus Notes, for unix. I know ODBC could work, that requires NotesSQL from what I understand, and Lotus only makes a windows version. Thanks in advance. -- Adam Not sure about this, but I know the latest linux notes server works with ODBC, but maybe thats not quite what you are asking. -- Nick Gorham Easysoft Ltd
[Fwd: DBD::ODBC make test fails]
Bill Kurland wrote: I am trying to use the perl DBI to connect to a product called U/SQL that gives me SQL like access to a COBOL ISAM database supplied by a VAR. My VAR pretty much only sells vanilla so I have been teaching myself how to program and was advised that perl was a very good first language. No regrets there, learning perl has been one of the more interesting and challenging things I've done in years - but I've hit a wall with this project and I hope one of you kind folks can offer some advice. This is a bit of a commercial question, but what format are your cobol files ? as we have somthing that works to C/D Isam files and works ok with DBD-ODBC on AIX 4.3 -- Nick Gorham Easysoft Ltd
Re: unixODBC and FreeTDS to MS SQL Server.
Jeff Urlwin wrote:
Well, I'm not especially solid on the FreeTDS. I did not realize that
FreeTDS supplied an ODBC driver. I thought that FreeTDS was to be used with
DBD::Sybase to talk to SQL Server
They do have a ODBC driver, but it is basic at the moment, the DBD:Sybase
option would be better supported, as the freeTDS coders are not that focused on
ODBC.
Jeff
Hi
I am having problems working with the DBD::ODBC driver.
I am using unixODBC and FreeTDS connecting to MS SQL Server. They
work well together and I have tested it. THe problem comes when I try
to use Perl DBD::ODBC (version 0.28). So, I know my DSN entery is ok.
This is the code (5 lines) and the Error I get. CAn you please tell
me why this may happen? I have tried searching for a week now.
#!/usr/bin/perl
use DBI;
use DBD::ODBC;
my $DSN
='driver={myserver};hostname=x.y.x;port=200;database=X;uid=x;pwd=x;';
my $dbh= DBI-connect(dbi::ODBC:$DSN) or die $DBI::errstr\n;
If you are using
driver={} then it needs to be the entry in odbcinst.ini not in odbc.ini, So I
would expect either
driver={TDS};...
or
dsn=myserver;...
The error I get is
DBI-connect() failed:[unixODBC][Drver Manager] Data source name
not found, and no default driver specified (SQL-IM002).
I have set the $DBI_DSN variable to dbi:odbc:myserver
I know the unixODBC and the free TDS have been installed right.
Can you help me with this?
Thanks
Amit
--
Nick Gorham
Emacs would be a great operating system if it just had a decent text editor...
Re: selector screws do in ODBC 0.28
Steve Howard wrote: If I'm following through this correctly, this is not a bug. ODBC only allows one active statement per connection. You are using the $hDB database handle for this statement: Well to be picky, its not ODBC but SQL Server that has that restriction, you can get around it by requesting a non forward only cursor on the statement, (ask for dynamic, and it will fall back to something lesser). However, beware, I can show a a 10 ODBC call program that can put SQL Server into a spin wait doing that :-( -- Nick Gorham Emacs would be a great operating system if it just had a decent text editor...
Re: selector screws do in ODBC 0.28
Steve Howard wrote: Nick, Picky is good. It was my understanding that this was an ODBC restriction. I've also seen the same error in the test bed in applications written in C and Java and that was the explanation we had come to accept No its a restriction of the SQL Server ODBC driver, not ODBC itself, there is a SQLGetInfo call (SQL_MAX_CONCURRENT_ACTIVITIES) that allows the application to check on this. I have to use this in both our SQLEngine and Kylix dbExpress driver to alter the operation, and create additional connections as required. I'm not arguing with you, but if the restriction is with SQL Server, then my understanding of something else needs to change. I might have a nebulous grasp on how this can be, but I would like to hear from someone else to (match|firm) up what I'm thinking. Well the restriction is with TDS the network protocol that SQL Server (And Sybase) uses. put simply in non dynamic mode one a query is executed dat just comes back, and keed comming untill the end, so there is no way (other that a cancel) to do anything else on that connection until all the results have come back. The ODBC driver checks this for forward only stmts, but for dynamic it doesn't. With these the data comes back a row at a time, so you can in theory muliplex statements. However the problem is that unless all the data is returned the protocol stream gets confused, hence the spin wait. The following ISQL script does the same sort of thing (it's bad practice to grant permissions to individual users, but it works as an example), but will not return an error, even though the grant is being executed while the usr cursor is still active in the established connection. Looking at the current activity while it takes place, it looks as if it handles it as a whole and not as individual statements (That's my current theory on how it's possible in an ISQL script), but profiler still shows a statement being prepared, executed, and individual fetches being done, and the grant statement being executed while usr is still active, and I don't see any additional connections being made - only the existing connection is referred to. Do you have a moment to take on explaining this? Well I would guess its because the script is operating on the server where the protocol restrictions dont apply, so there will be no such problem. Of course I could be wrong, this is all just summise. MS could give you a exact answer, but I doub't they would :-) -- Nick Gorham Emacs would be a great operating system if it just had a decent text editor...
Re: ANNOUNCE: DBD::Oracle 1.12
Tim Bunce wrote: For VMS I need tested patches - I'm not able to test on VMS myself. Tim. Not sure if you want to know this, but Compac (Or Hpac :-) have some publically available VMS machines available (I think they had Oracle on AFAIK. On Fri, Sep 14, 2001 at 01:44:29PM -0400, John Peacock wrote: Tim Bunce wrote: file: $CPAN/authors/id/T/TI/TIMB/DBD-Oracle-1.12.tar.gz size: 172858 bytes md5: 89f33ade9fbbdb09e07178339ee44f4f More feedback. Under VMS using Oracle7, it is required to use the LNOCIC linker file instead of the LNPROC in order to get the files to link properly. I cannot confirm that this is true with the full blown Oracle, as we only have the Oracle client libraries (plus what demo files were needed to build DBD::Oracle). I know that I sent you an e-mail about this last year, but it probably slipped off your list. You should also be aware that the test suite (t/*.t) does not print out properly under VMS, due to the way that output is handled. The tests run, but they print out like this: t/base.. ok t/general... ok t/long.. ok t/ph_type... ok t/plsql. ok If it would help, I can try and type up a README.vms with some of the gotchas that are likely to strike. For example, in order to run the tests successfully on a remote database, ORACLE_USERID must be set define ORACLE_USERID scott/tiger@database which is how VMS sets %ENV variables. In addition, I thought I would point out that your README.login is not helpful; it suggests using 'perldoc DBD::Oracle' to read the module documentation. However, if I'm are trying to test, I haven't yet installed the module, so Or use 'perldoc Oracle.pm' if you have not yet installed the module. would be an appropriate addition. Thanks John -- John Peacock Director of Information Research and Technology Rowman Littlefield Publishing Group 4720 Boston Way Lanham, MD 20706 301-459-3366 x.5010 fax 301-429-5747 -- Nick Gorham Don't worry, be happy
Re: DBD::ODBC connection issue to SQL Server
Tim Harsch [EMAIL PROTECTED] wrote: Hi all, I have MS SQL Server 2000 on Win2K as my server, running EasySoft's ODBC:ODBC bridge server software. I have Red Hat Linux 7.1 as my client, running EasySoft ODBC:ODBC Client sofware. With DBI and DBD::ODBC installed. This is more of a OOB question than a DBD specific one, I will copy it to [EMAIL PROTECTED] I will try and reproduce the situation on Monday. I can't do it now, as I don't have direct access to the NT servers. I am able to make connections to the server but am a little perplexed by a few thigs... First of all, for security purposes I wish my logon User to have as few permissions as possible on the Win2K network (ie just enough to get on the network and pass along the TargetUser to SQL Server). Through experimentation I have discovered a couple of disturbing requirements to allow the connection to be made. First, the Windows user must be included in the Account Operators group. Now, I'm no wizz at Win2K but am betting that that group has one specific permission that is needed by the LOGONUSER. I can probably determine what it is later. But, 2nd, this LOGONUSER must have a SQL Server account that connects via Windows authentication (trusted connections). This might be because, it is always logging on as user guest, even though I set TargetUser and TargetAuth to some other user in both the odbc.ini file and the DBI connect string. Any ideas? __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ -- Nick Gorham When I die, I want to go like my grandfather did, gently while sleeping, and not like his passangers, screaming in a panic, looking for the inflatable raft. -- Seen on ./
Re: ODBC connects, but queries fail.
[EMAIL PROTECTED] wrote: Big Brother tells me that Neil Lunn wrote: Umm Jack. The main point was to see if there was a difference between isql and DBD::ODBC. isql should allow you to use the same connect string that you are suppling to DBD::ODBC, so if you can supply a DSN'less connect to isql, the same string can be used for DBD::ODBC. EXACTLY!! This is the point I have been trying to make. The DSN works just fine. Now at the end of the day, if this fails as before there is something wrong with DBD::ODBC, but if it works then something is up with how odbc.ini is being processed. This has been my conclusion. Since unixODBC+FreeTDS is working outside of perl, the only new element is DBD::ODBC. Yes, but ODBC is not that clear cut. There are many ways to do the same thing, one set of ways may work using isql (for instance), but DBD::ODBC may use another set of ways, this doesn't mean its DBD at fault, it could still be the driver, not doing what it should. Have you tried creating a ODBC trace of what is going on, that may help (send me a copy if you want.) -- Nick Gorham Easysoft Ltd
Re: [unixODBC-DEV] - DBI::ODBC unixODBC timestamp problem
[EMAIL PROTECTED] wrote: denblueuser@dbi:ODBC:SYBTEST select VALUE_DATE from TRADE_BASIC/ VALUE_DATE '2001-01-02 00:00:00.00.' [snip] When I looked with the perl debugger the final chars were \c@. Has anyone else come across this? Is there a work around? Could you provide a ODBC trace of whats going on, I am tempted to suggest it is a driver issue, the driver manager doesn't involve itself with data returned from the driver, but the trace would help verify just what is going wrong. -- Nick Gorham Easysoft Ltd
