strange DBI behaviour

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

Dear Monks!

You are my last chance to survive this crisis I am battling now. Not easy to describe the problem, but I will try. I do develop as a member of a project which is an economical software for the internet, using MSSQL6.5 (oh god why:(((), php, perl.

There are two platforms, they were planned to be identical, one is for development, and one for test. They are DEC Alpha systems with Tru64 OS. Until this it is very nice, eh besides MSSQL. MSSQL resides on 2 NT machines. I created some pages with php and perl for users to provide their datas and orders. Everything was beautiful until we copied the whole stuff into the test machine.

It returned some really strange error messages when we requested the same pages. While they worked well on the develop machine, they crashed on the test machine. It said there is no database table which must be there because I checked through MSSQL query at the NT machine and I checked it through some perl scripts I wrote for accessing queries from MSSQL. Finally I realized that every query works well, until I try to send a subquery while an $sth is opened. When no statement handler is present there is no error. When I use a subquery (starting $sth2 for example, it just dies.

So I must call the external perl scripts, because they are running in an other database handler, so there is no conflict. Is not it funny? I am frustrated.

I dont want to paste any code here, because I know that the problem is not in that. The problem must be some incompatibility, so:

develop machine: perl: version 5.004_04 built for alpha-dec_osf, DBI: 1.13
test machine: perl: version 5.005_03 built for alpha-dec_osf, DBI: 1.14

All machines have DBD::Sybase 0.23 and 'freetds' to connect MSSQL. Any help could save my life.

thank you

-- tune

Comment on strange DBI behaviour Select or Download Code

Replies are listed 'Best First'.
Re: strange DBI behaviour by qi3ber (Scribe) on Nov 17, 2000 at 20:07 UTC
I have a feeling that the problem is related to the fact that your perl and DBI versions are different between the two boxen. I wonder if upgrading the development machine to be the same as the production machine would produce the same error. Alternative downgrading the production machine might make the error go away. [ qi3ber ] I used to think that I knew it all, then I started to listen.	[reply]
Re: strange DBI behaviour by PsychoSpunk (Hermit) on Nov 17, 2000 at 23:31 UTC
Okay, I'm running under the assumption that the dev machine hits one of the NT boxen, while the test machine hits the other. Let me know if this is incorrect. What's your $ENV{TDSVER} set to? With MSSQL 6.5, you should have both of the DECs set to '42'. I don't think this is related to your inconsistent DBI versions, since your test machine is actually higher versions of both Perl and DBI. However, the key here may be the DBD version. I'm not 100% sure that FreeTDS has been tested with 0.23. The FreeTDS website lists 0.20, but it's been that way for a while. I'm also trusting that you followed instructions for building the libs. You say that the code works on the dev machine, but not the test machine. Is it the exact same code? Finally, you may wish to subscribe to DBI Users mailing list. I've seen the problem you refer to, but aside from creating a second dbh, I've not solved it. My own problem lies in the fact that only about half of my subqueries produce this error, so I haven't been as perturbed by it. ALL HAIL BRAK!!!	[reply]