Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Sybperl 2.18 and temporary tables

by Redwing (Initiate)
on Jan 27, 2011 at 22:45 UTC ( #884680=perlquestion: print w/replies, xml ) Need Help??

Redwing has asked for the wisdom of the Perl Monks concerning the following question:

We've recently upgraded to Sybperl-2.18 (the Sybperl module not the DBlib or CTlib modules) after having used an earlier version for many years now. We're experiencing a problem we didn't have under the old version and I'm hoping it can be solved simply with a configuration setting (although I'm not seeing anything in the documentation which sounds like the appropriate option) nor on this site although my search arguments may not reflect those found in a pertinent article.

We have quite a few perl scripts which feed a SQL string to &dbsqlexec which do the following:

1. Select rows from a permanent table into a temporary table:

select * into <i>#temporarytablename</i> from <i>permanenttablename</i>
2. Then select rows out of the temporary table:
select * from <i>#temporarytablename</i>
This is all within the same SQL string fed to &dbsqlexec and all within the same connection. What happens is we get no rows returned from the temporary table nor do we get any error message.

This doesn't happen under the earlier version of Sybperl. If we change the temporary table to a permanent table it works perfectly (but this is not an option for us). If we execute the code with the temporary table references under iSql or via SQLAdvantage it works fine so it definitely seems to be the new version of Sybperl (or it's configuration) which is the problem.

Any assistance you can offer would be greatly appreciated.

Redwing

Replies are listed 'Best First'.
Re: Sybperl 2.18 and temporary tables
by wjw (Priest) on Jan 28, 2011 at 00:47 UTC
    I have zero experience with Sybase or Sybperl, but some things I would check are:
    • are you actually creating the temp table? Maybe break the single exec into parts to ensure each piece works
    • permissions, has the upgrade changed the user that the DB connection is made as? Can the current user connection create tables?

    I have been burned by these types of things before when I updated a module. Figured I would toss those out...

    • ...the majority is always wrong, and always the last to know about it...
    • The Spice must flow...
    • ..by my will, and by will alone.. I set my mind in motion

      Thanks wjw,

      Actually the problem code works under the previous version. And all other code (except any code which looks to return rows from a temporary table) works fine under the new version so the connection and permissions must be correct. It really seems as if the 2.18 version of Sybperl lacks the functionality the 1.x versions had. The Sybperl::DBlib module also seems to have the same problem. Haven't had a chance to check the Sybperl::CTlib module yet.

      Anyway, thanks for your response! Redwing.

Re: Sybperl 2.18 and temporary tables
by mpeppler (Vicar) on Feb 03, 2011 at 08:02 UTC
    Yikes!

    I didn't know that anyone still used the Sybperl.pm module!

    Could you please post an actual bit of perl code that illustrates the problem (with a generic SQL statement, maybe a select from sysobjects or something like that) so that I can try to reproduce it?

    Thanks.

    Michael

      Michael,

      Thank you for your reply.

      Yikes indeed - I'm afraid in this new job I started I've gotten into a sort of an "Office of the Future in the Land That Time Forgot" type situation. One of the other technologies they're asking me to upgrade is 22 years old! (dtksh).

      At any rate I remembered a similar problem with Sybase::CTlib from years ago and realized what I was doing wrong. For the edification of others who are putting in far too many hours:

      My problem code looked like this:

      &dbcmd($proc, "SELECT crdate into #tmp_table FROM sysobjects \n"); &dbcmd($proc, "SELECT * FROM #tmp_table \n"); &dbsqlexec($proc);

      What I was forgetting was that when you're doing a select into a table followed by a select out of that table you need an additional &dbsqlexec($proc); in between the 2 statements the same way you need an intervening &executesql; when using Sybase::CTlib:

      &dbcmd($proc, "SELECT crdate into #tmp_table FROM sysobjects \n"); &dbsqlexec($proc); &dbcmd($proc, "SELECT * FROM #tmp_table \n"); &dbsqlexec($proc);

      Now I can gleefully return to upgrading those 22 year old dtksh CGI scripts to the latest 17 year old version!

      Thanks very much for taking the time to respond! Redwing

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://884680]
Approved by Corion
Front-paged by Corion
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (6)
As of 2020-12-04 15:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    How often do you use taint mode?





    Results (60 votes). Check out past polls.

    Notices?