Re: Connecting from Linux onto MS-SQL-Server
Hi Alexander, yeah that was my first idea the customer came to me but it's not possible because the Win-Server is not under my control and the other side is not willing to install anything onto their system. Tom Alexander Foken schrieb: Did you think about using DBD::Proxy on Linux and ActivePerl + DBI::ProxyServer + DBD::ODBC on Windows? http://search.cpan.org/~timb/DBI-1.51/lib/DBI/ProxyServer.pm http://search.cpan.org/~timb/DBI-1.51/lib/DBD/Proxy.pm http://www.activestate.com/Products/ActivePerl/ Costs: Zero. Source: Open. License: Artistic. Performance: Perhaps not the fastest solution. But hey, it's free! Alexander On 10.06.2006 14:58, Tom Schindl wrote: Hi, I read the POD of DBD::ODBC but there's only the commercial from http://www.openlinksw.com mentionned, isn't there an open version available? I only need read access from Linux to MS-SQL. Tom signature.asc Description: OpenPGP digital signature
Re: Connecting from Linux onto MS-SQL-Server
Hi Dean, thanks that sounds promising, I'll give it a try. Many many thanks Tom Dean Arnold schrieb: On 10.06.2006 14:58, Tom Schindl wrote: Hi, I read the POD of DBD::ODBC but there's only the commercial from http://www.openlinksw.com mentionned, isn't there an open version available? I only need read access from Linux to MS-SQL. Tom You may be able to get by with DBD::Sybase and FreeTDS: http://www.freetds.org/ http://search.cpan.org/~mewp/DBD-Sybase-1.07/Sybase.pm HTH, Dean Arnold Presicient Corp. signature.asc Description: OpenPGP digital signature
Re: DBD::mysql 3.0006 and 3.0006_1 released
Patrick Galbraith wrote: * To turn off server-side prepare statements to have emulated prepared statements, append ;mysql_emulated_prepare=0 in the connect string or via the driver handle. Shouldn't that be ;mysql_emulated_prepare=1 ? Also, I see that as of 3.0004_1 UTF-8 support has been added. I've lost count of the number of times that people (including myself) have asked for this, so it's great to see it at last. Did I miss the announcement about this? I don't recall seeing one, and it isn't even mentioned in the documentation: you have to read the ChangeLog (or the source code!) to find it. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: DBD::mysql 3.0006 and 3.0006_1 released
(I don't like cross posting so my reply is restricted to dbi-users) On 12-Jun-2006 Steve Hay wrote: Patrick Galbraith wrote: * To turn off server-side prepare statements to have emulated prepared statements, append ;mysql_emulated_prepare=0 in the connect string or via the driver handle. Shouldn't that be ;mysql_emulated_prepare=1 ? Also, I see that as of 3.0004_1 UTF-8 support has been added. I've lost count of the number of times that people (including myself) have asked for this, so it's great to see it at last. Did I miss the announcement about this? I don't recall seeing one, and it isn't even mentioned in the documentation: you have to read the ChangeLog (or the source code!) to find it. To my knowledge it was not announced but was discussed on the dbi-dev list and it is under development still for the reasons given in: See my posting http://www.nntp.perl.org/group/perl.dbi.dev/4550 and http://bugs.mysql.com/bug.php?id=19814 i.e. it is only in the development release _1 and is somewhat stalled because no one can categorically say what charsetnr should contain for UTF8 and there does not appear to be a definitive defn for SET NAMES and SET CHARACTER SET. Having said that, it works for what I'm doing but I don't have an non-ASCII table names and I only have ASCII and UTF8 data. Martin -- Martin J. Evans Easysoft Ltd, UK http://www.easysoft.com
Install problems with DBD::ODBC
Running perl 5.8.1 (multi-thread - beyond my control) on SUSE 9.2. DBI is 1.48. DBD::Oracle works OK. Am attempting to get ODBC working in order to connect to Progress Database. ODBC drivers (with appropriate Progress license) installed; Progress version 9.1E. The PROGRESS/UNIX/ODBC drivers are actually written by MERANT, Inc. (Speed-readers please note, this is Progress, not Postgres)!! Progress-supplied Drivers have names like pgpro918.so, odbctrac.so, etc., so I have followed instructions for Solaris, where UNIX flavors differ. Testing fails with simple test 4 - Auto commit retrieved to what was set. Error message Unable to find a suitable test type for field COL_C at t/ODBCTEST.pm line 64. And from there on the test results go downhill. Any pointers on how to get up and running will be appreciated. Thanks and regards, Sam Carmalt Background of warnings, etc., prior to running make test *** Problems solved (I think) so far: -- Lines 41, 42, 90 91 of dbdimp.h start with /* in the middle of a comment ( /* ... */ ); hand-edited include file to ** in each of these 4 instances. -- No supplied sqlucode.h file, so have used the one in the demonstration verions of DataDirect drivers. Seems to be unicode stuff. *** Running perl Makefile.PL then gives the following: Useless use of private variable in void context at Makefile.PL line 431. Using ODBC in /usr/local/dlc/odbc Umm, this looks like a unixodbc type of driver manager *** Running make seems to be OK, although there are a number of warning messages: Warning: duplicate function definition 'data_sources' detected in ODBC.xs, line 202 dbdimp.c: In function `odbc_clear_result_set': dbdimp.c:143: warning: unused variable `inner' dbdimp.c: In function `dbd_preparse': dbdimp.c:1159: warning: unused variable `param' dbdimp.c: In function `odbc_describe': dbdimp.c:1614: warning: unused variable `t_dsize' dbdimp.c: In function `odbc_st_finish': dbdimp.c:2412: warning: unused variable `ret' dbdimp.c: In function `_dbd_get_param_type': dbdimp.c:2509: warning: unused variable `supported' dbdimp.c:2909:65: warning: /* within comment dbdimp.c: At top level: dbdimp.c:2958: warning: return type defaults to `int' dbdimp.c: In function `odbc_db_STORE_attrib': dbdimp.c:3078: warning: unused variable `imp_drh' dbdimp.c:3083: warning: unused variable `cachesv' dbdimp.c: In function `odbc_db_FETCH_attrib': dbdimp.c:3325: warning: unused variable `imp_drh' dbdimp.c: In function `odbc_st_STORE_attrib': dbdimp.c:3695: warning: unused variable `imp_dbh' dbdimp.c:3699: warning: unused variable `value' *** Then make test starts failing with t/02.4
request for clarification, was (DBD::DB2 execute and finish problem)
Hi,
DBI documentation says execute on a an active statement should imply a finish
call but DBD::DB2 does no appear to do this - see example below.
This issue is now causing me a severe amount of grief as we have no finish
calls anywhere in our code and we are finding more and more cases where finish
would have to be called when using DBD::DB2 but not for any other DBD we use.
This is a significant incompatibility between DBD::DB2 and other DBDs (like O
DBC and mysql and Oracle). Can someone please clarify if this is a DBD::DB2 bug
or a DBI bug in the documentation or something else.
Thank you.
Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com
On 09-Jun-2006 Martin J. Evans wrote:
Hi,
I'm using DBD::DB2 0.78 and DBI 1.51. I am finding that code which is working
to DBD::ODBC and DBD::mysql fails with invalid cursor state but inserting a
call to finish makes it work. Up until now, I've never used finish because
the
docs say:
If execute() is called on a statement handle that's still active
($sth-{Active} is true) then it should effectively call finish() to tidy up
the previous execution results before starting this new execution.
and
The finish method is rarely needed, and frequently overused, but can
sometimes
be helpful in a few very specific situations to allow the server to free up
resources (such as sort buffers).
When all the data has been fetched from a SELECT statement, the driver should
automatically call finish for you. So you should not normally need to call it
explicitly except when you know that you've not fetched all the data from a
statement handle. The most common example is when you only want to fetch one
row, but in that case the selectrow_* methods are usually better anyway.
Adding
calls to finish after each fetch loop is a common mistake, don't do it, it
can
mask genuine problems like uncaught fetch errors.
An example is:
create table fred (a int not null primary key)
insert into fred values (1)
insert into fred values (2)
insert into fred values (3)
perl -w -e 'use DBI; my $dbh = DBI-connect(dbi:DB2:mydsn, xxx,
yyy); my @a = (1,2,3); $sth = $dbh-prepare(q/select * from fred where a
= ?/); foreach my $a (@a) {$sth-execute($a); my @row =
$sth-fetchrow_array;}'
which returns:
DBD::DB2::st execute failed: [IBM][CLI Driver] CLI0115E Invalid cursor
state.
SQLSTATE=24000 at -e line 1.
This seems to fall into the category of the first quote from the docs which
suggest finish should be called for you. I don't want to add the finish if it
should not be required and this is a huge amount of code to work through
anyway. I know I could possible avoid the issue if I used selectall_* but
here
again, I'd have to check a lot of code to make this change.
Is this a bug in DBD::DB2?
Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com
Re: Install problems with DBD::ODBC
Why don't you use DBD::Pg? perl -MCPAN -e install 'DBD::pg' Alexander On 12.06.2006 16:24, [EMAIL PROTECTED] wrote: Running perl 5.8.1 (multi-thread - beyond my control) on SUSE 9.2. DBI is 1.48. DBD::Oracle works OK. Am attempting to get ODBC working in order to connect to Progress Database. ODBC drivers (with appropriate Progress license) installed; Progress version 9.1E. The PROGRESS/UNIX/ODBC drivers are actually written by MERANT, Inc. (Speed-readers please note, this is Progress, not Postgres)!! Progress-supplied Drivers have names like pgpro918.so, odbctrac.so, etc., so I have followed instructions for Solaris, where UNIX flavors differ. Testing fails with simple test 4 - Auto commit retrieved to what was set. Error message Unable to find a suitable test type for field COL_C at t/ODBCTEST.pm line 64. And from there on the test results go downhill. Any pointers on how to get up and running will be appreciated. Thanks and regards, Sam Carmalt Background of warnings, etc., prior to running make test *** Problems solved (I think) so far: -- Lines 41, 42, 90 91 of dbdimp.h start with /* in the middle of a comment ( /* ... */ ); hand-edited include file to ** in each of these 4 instances. -- No supplied sqlucode.h file, so have used the one in the demonstration verions of DataDirect drivers. Seems to be unicode stuff. *** Running perl Makefile.PL then gives the following: Useless use of private variable in void context at Makefile.PL line 431. Using ODBC in /usr/local/dlc/odbc Umm, this looks like a unixodbc type of driver manager *** Running make seems to be OK, although there are a number of warning messages: Warning: duplicate function definition 'data_sources' detected in ODBC.xs, line 202 dbdimp.c: In function `odbc_clear_result_set': dbdimp.c:143: warning: unused variable `inner' dbdimp.c: In function `dbd_preparse': dbdimp.c:1159: warning: unused variable `param' dbdimp.c: In function `odbc_describe': dbdimp.c:1614: warning: unused variable `t_dsize' dbdimp.c: In function `odbc_st_finish': dbdimp.c:2412: warning: unused variable `ret' dbdimp.c: In function `_dbd_get_param_type': dbdimp.c:2509: warning: unused variable `supported' dbdimp.c:2909:65: warning: /* within comment dbdimp.c: At top level: dbdimp.c:2958: warning: return type defaults to `int' dbdimp.c: In function `odbc_db_STORE_attrib': dbdimp.c:3078: warning: unused variable `imp_drh' dbdimp.c:3083: warning: unused variable `cachesv' dbdimp.c: In function `odbc_db_FETCH_attrib': dbdimp.c:3325: warning: unused variable `imp_drh' dbdimp.c: In function `odbc_st_STORE_attrib': dbdimp.c:3695: warning: unused variable `imp_dbh' dbdimp.c:3699: warning: unused variable `value' *** Then make test starts failing with t/02.4 -- Alexander Foken mailto:[EMAIL PROTECTED] http://www.foken.de/alexander/
Displaying fetched values in html form
I'm not sure if this is the right forum so i'd appreciate pointers to the correct place if i'm wrong. I've got DBI running between apache and an Oracle 10gR2 database. I can insert data with no problem. Here's what i'm attempting to do. 1. Put up a HTML form where user enters his userid, password, and emailid. 2. I pass this information t a perl module and verify his user exists in the database. 3. If successfully validating this user I get account information from the database, put up a html form, and post that information to text boxes in the html form. The problem i'm having is returning the data to the text areas in the form. I can print the data coming back from the database so that piece is working. When I set the value in the text box to $username in the text box I get $username instead of what was returned from the database. I can print the actual returned username by doing a print of $username variable but outside the text block. Ultimately I would like the user to be able to make changes to their user information then i'll update the database. I'm sure this can be done and that means i'm probably looking past something really obvious. Google has not been much use. Any ideas? Stumped
Re: Displaying fetched values in html form
On Mon, 12 Jun 2006 14:50:55 -0700, Kevin Moore wrote: Hi Kevin It's impossible to debug invisible code (without loading the Telepathy module :-), so posting it would help. As for the forum, your description does not suggest a DBI problem, but rather a general Perl problem. Hence I suggest the newsgroup comp.lang.perl.misc. -- Cheers Ron Savage, [EMAIL PROTECTED] on 13/06/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company
Re: request for clarification, was (DBD::DB2 execute and finish problem)
On Mon, 12 Jun 2006 15:24:55 +0100 (BST), Martin J. Evans wrote: Hi Martin This seems to fall into the category of the first quote from the I saw the original post, and expected someone else to answer. I don't agree that it falls in the first category. I strongly suspect you'll have to amend all (sic) your code, to call 'finish' /unless the 'fetch' exhausts the returning data/. I think you're reading the docs based on wishful thinking and not on what they really mean. -- Cheers Ron Savage, [EMAIL PROTECTED] on 13/06/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company
Re: Install problems with DBD::ODBC
On Mon, 12 Jun 2006 17:37:22 +0200, Alexander Foken wrote: Hi Alexander Why don't you use DBD::Pg? because, as OP was kind enough to explain... (Speed-readers please note, this is Progress, not Postgres)!! unless of course you have some reason for believing the PostgreSQL driver will work with Progress :-)). -- Cheers Ron Savage, [EMAIL PROTECTED] on 13/06/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company
Speed test for connecting to Oracle for Windows via ODBC
Hi Folks Using a DSN of dbi:ODBC:xyz, the DBI - connect(...) call takes 16 (sic) seconds with both the Perl script and Oracle running on the same PC under Windows. You have been warned :-(. -- Cheers Ron Savage, [EMAIL PROTECTED] on 13/06/2006 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company
