Up Prev Next
From: Tim_Green at mercer dot com
Subject: RE: out of sync message
Date: Jun 4 1998 10:14PM
Reading messages about problems using Sybase sessions across forked processes
really makes me nervous, and this subject tends to come up quite a bit. I've
never run into a problem doing this and know that it's not because of any skill
on my part.
A critical part of our system was rewritten in Sybperl about 18 months ago, and
it relies heavily on a parent process establishing a connection to the server
and then handing it over to a spawned child process. It has worked flawlessly
in production for over a year.
We're running on HP-UX 10.20, Sybase 11.0.2, Open Client 10.0.4, perl 5.003 and
Is there anyone who's been following this thread (or the others that have been
discussed about forked processes and Sybperl) who can explain what problems
there are with this approach? Are there specific things that you can't do
within the parent or the child process that cause Sybase libs to complain? I'd
just like to know what I've done (or not done) to avoid the multitude of
problems I've heard others run across.
Sometimes it's better to be lucky than smart!
Tim Green Tim_Green@mercer.com
Administrative Solutions Group
An ADP/Mercer Alliance
> Interesting to hear that!
> I really didn't solve the problem of the fork. In our
> case, the time spent to do the update was pretty small,
> and so it was not really necessary to do the fork'ed
> off task. Had it been necessary, I had contemplated
> actually having a second perl program that did the
> task that was to be forked. Then the main prog would just
> run the other prog when necessary.
> -----Original Message-----
> > You know, I've fought that same error pair...
> > Sybase error: Datastream processing out of sync.
> > Sybase error: DBPROCESS is dead or not enabled.
> > as well. I never figured out exactly what was causing the
> > problem, but it was centered in some code that was being
> > fork'ed off to do an update in the background. When I
> > finally tossed the fork method, the errors went away.
> > Don't ask me what fixed what, but the errors went away.
> > I've got my Sybperl error traps for our site set to email
> > me w/all the error info, perl call dumps, etc. and I was
> > getting tired of coming in to find 45 SQL/perl warnings
> > waiting for me in the mailbox!
> > Tim Holt, Rogue Wave Software
> Thank you for your insights regarding this problem. As it turns out, I
> also doing forks in the script. I am wondering what other alternatives
> used if any. I am also interested to know if you ever implemented a
> like cancel request for an ongoing Sybperl query or a batch
> of commands.
> Thank You
> Simon Yaminian