Jung S. Lee wrote:
>
> matt wrote:
>
> > Jon Winchester wrote:
> >
> > > We tried to port out application to Sybase and experienced some
strange
> > > problems. The one killer that we were never able to clear up, even
after
> > > bringing in a Sybase expert consultant was that it appeared to
convert
> > > every SQL that we sent to it from our app (VB via ODBC calls direct
through
> > > ODBC API) into system stored procedures and then execute them.
> > >
> > > While the performance was good, it would build up these stored
procedured
> > > and would begin to slow down. The only fix that we found was to shut
down
> > > the server daily to clear them out.
> > >
> > > I am sure there is a way to work with the server so that this does
not
> > > happen, but we (admitted Sybase non-experts) were unable to find it
as
> > > was our supposed Sybase expert.
> > >
> > > Jon
> > Something is strange here. Sybase doesn't just create stored
> > procedures. It sounds like some foreign application is doing it.
> >
> > I'm curious, get in touch if you want to discuss more
> >
> > matt townsend
> > mtownsend_at_nlight.com
>
> It's ODBC that creates temp store procedures. A while back, I worked on
> a project used MS Access front end to Sybase back end. There is an
> option you can turn on to delete these store procedures after their
> executions. Another problem I had is recordset. If you are not careful
> in your codes, it will download whole table or large chunk of data. And
> other problems like how to update recordset and others. But we got it to
> work to user requirements and implemented it at client site. I don't
> know if they are still using it......
>
> --
> Jay Lee Lake Mary, FL
As I said, it didn't look like a Sybase problem
Received on Thu Jun 12 1997 - 00:00:00 CDT
