Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: ggs at tpd dot eds dot com (Gary_Sanders)
Subject: Re: Problems with writing text
Date: Jan 25 1996 5:18AM

Rob Osattin writes:


First, this is not meant as a flame.  Have you considered using Perl 5
and Micheal Pepplers (sp?) version of Sybper?  We have been using it
very successfully for some time now (knock on wood).  

BTW, I, myself, have never even programmed a line of 'C' code myself
to talk to Sybase so I'm afraid I can't be of much help in that

Gary Sanders

 > Date	1/24/96
 > Subject	Problems with writing text 
 > From	Rob Osattin
 > To	Sybperl Mailing List
 > CC	Keith Dryden, Don Morris
 >                       Problems with writing text data
 > Dear fellow Sybperl'ers,
 > My company uses a turnkey  client/server system with mac clients and Sun
 > servers running Sybase 10.0 under Solaris.  The software includes sybperl
 > programs that run under perl 4 to perform limited utility functions but we
 > wanted more so we wrote a sybperl program ourselves
 > But it doesn't work right. We're stumped and the vendor is useless. HELP!!
 > The purpose of the program is to continuously scan directories on the Sun
 > and copy the contents of all files found to rows in a certain table. Each
 > file goes into a text column in its own row. What we're seeing is that,
 > after a while, files are being run together- the text in the most recently
 > created row includes all the text of every row previously written since the
 > program was started. This is not good!
 > I'm suspecting that we've made some mistakes in either the &dbwritetext call
 > or have done something resulting in memory corruption. By the way, our
 > debugging shows that the contents of all perl variables are correct before
 > each call. The text presented to the writetext is, in all cases, what it
 > should be. It's not run together.
 > Here's the main logic outline. I'd appreciate any comments or criticisms you
 > might have. Please, no flames, it's our first sybperl. (I hope my metacode
 > is okay)
 >  ($dbproc1)   &dblogin
 >  ($dbproc2)   &dblogin
 >  ($dbproc1)   &dbuse
 >  ($dbproc2)   &dbuse
 >  ($dbproc1)   &dbsql (cmd+exec)  "set nocount on"
 >  .
 >  .
 >  file loop
 >     if file in directory
 >           ($dbproc1) &dbsql (cmd+exec) insert new row into story table
 > providing values for several columns      ***note the text column is not set
 > to anything here***
 >            read the contents of the file into variable $storyText ***this
 > variable looks fine each time ***
 >           ($dbproc1)  &dbsql (cmd+exec) update the row, setting a non text
 > column
 >           ($dbproc1)  &dbsql (cmd+exec) update the row, setting text column
 > to NULL
 >           ($dbproc2)  &dbsql (cmd+exec) select the text column from the row
 >           if &dbresults($dbproc2) != $NO_MORE_RESULTS
 >               repeatedly execute  ($dbproc2) &dbnextrow until results are 0
 > or null
 >               endif
 >            &dbwritetext($dbproc1, "story.text',$dbproc2,1,$storyText)  
 > ***actual statement***
 >            ($dbproc1)  &dbsql (cmd+exec) update the row with additional info
 > for other colums #1
 >            ($dbproc1)  &dbsql (cmd+exec) update the row with additional info
 > for other colums #2
 >            ($dbproc1)  &dbsql (cmd+exec) update the row with additional info
 > for other colums #3
 >        end of "if file in directory"
 >  end of file loop
 > Note that we're not using begin trans or commits. Could this be a problem?
 > Also,  although I didn't show it, we're checking the return status from each
 > call and are rolling back and exiting if a non zero status is returned.
 > I apologize for being so wordy here but this is the only way I know to
 > describe the problem.
 > I hope you Sybperl gurus can help. If not, I fear my management is going to
 > be so afraid of development in Sybperl that they'll force us either to C or
 > *choke* Cobol.
 > Please save us.
 > Thanks.
 > Rob Osattin
 > Atlanta Journal-Constitution
 > Atlanta, GA