[Date Prev][Date Next][Thread Prev][Thread Next]
[Author Index]
[Date Index]
[Thread Index]
[SQR-USERS Info]
[SQRUG Home Page]
Re: err. 004729 Cannot find inactive database cursor. Program too large.
- Subject: Re: err. 004729 Cannot find inactive database cursor. Program too large.
- From: Mark Risman <mrisman@PAINEWEBBER.COM>
- Date: Fri, 24 Mar 2000 11:34:01 -0500
Ray,
What I was thinking (but I admit I didn't make all that clear) was that all SQR would have to would be to be able to (a) generate a suitable name for a temp table, like it does already, when it calls them "SQR...."; it could create the table in the current database, and (b) drop the table when the SQR is finished executing. I wasn't suggesting that SQR have its own table structure.
- Mark
-----Original Message-----
From: Ray Ontko [mailto:rayo@ONTKO.COM]
Sent: Thursday, March 23, 2000 11:02 PM
To: SQR-USERS@list.iex.net
Subject: Re: err. 004729 Cannot find inactive database cursor. Program too large.
Mark,
I assume that the historical reason for not including temp tables
in SQR has to do with not wanting to add the overhead for a miniature
SQL implementation. I assume that you'd want to be able to INSERT,
UPDATE, DELETE, GROUP BY, ORDER BY, etc. This is a lot of overhead,
I expect.
I agree that it would be a nice feature.
Ray
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Here's a thought then, regarding temporary tables, directed at the Brio people who are listening / lurking out there.
>
> Why doesn't SQR have its own temp table facility? It can have its own logic for determining actual table names, transparently to the SQR programmer. This could also allow the use of one method of implementing temp tables that is not database-specific, as the database-specific logic could be built directly into the SQR package.
>
> - Mark
>
> -----Original Message-----
> From: Jerry Keith Neal [mailto:jkneal@INDIANA.EDU]
> Sent: Saturday, March 18, 2000 4:10 PM
> To: SQR-USERS@list.iex.net
> Subject: Re: err. 004729 Cannot find inactive database cursor. Program too large.
>
> Thanks for the suggestions. I have tried increasing the queries in the M
> file with no results. You are correct about oracle not supporting
> temptables. This has been our major obstacle in converting to oracle. To
> overcome this we create these as permanment tables in the users schema
> that get droped in the nightly build. I would like to know more about the
> error. The sqr users manual says to reduce the complexity of the report
> for a fix which is not an option for us at this point. When sqr runs a
> cursor does it keep it open to the end of the report? If so , would there
> be any way to help close some of these? We have tried putting commits
> after each sql statement but this has not corrected the problem. We would
> like to reslove the problem without modifying the code too much, but if
> needed I will consider trying to combine some of the sql statements or the
> use of stored procedures.
>
> thanks again,
> Jerry
>
> On Fri, 17 Mar 2000, Arjan Hoornstra wrote:
>
> > That's what you get from downgrading from Sybase to
> > Oracle... but seriously, I think there maybe some
> > possiblities:
> > - use -M option to increase number of queries
> > - combine seperate procedures by increasing the number
> > of joined tables in a query
> > - use stored procedures rather than sqr procedures for
> > insert/update/delete stuff
> > - use temptables for storage... oh wait, Oracle
> > doesn't have a tempdb, right? create some tables then
> > for intermediate storage
> >
> >
> >
> >
> > --- Chris Shelton <cshelton@INDIANA.EDU> wrote:
> > > I'm working with Jerry in trying to resolve this
> > > problem, and wanted to
> > > provide some additional details. The 4729 error
> > > comes from SQR, and has
> > > this description provided in the manual:
> > >
> > > The program has too many concurrent database
> > > cursors. Reduce the
> > > complexity of the program.
> > >
> > > We are in the process of converting many SQR reports
> > > from sybase to
> > > oracle. This same report has worked perfectly
> > > against our sybase ASE
> > > 11.5.1 database for a couple of years now. After
> > > modifying all sybase
> > > specific SQL statements so that they work with
> > > oracle 8.1.5, we receive
> > > this error during the compilation step in the
> > > report.
> > >
> > > We have tried several possible resolutions to this
> > > problem, including:
> > > - adding commit's after each insert statement in
> > > begin-sql paragraphs,
> > > - increasing the value of the open_cursors database
> > > parameter from 300 to
> > > 1000, and
> > > - increasing the amount of stack space available to
> > > OS processes.
> > >
> > > None of these changes have made any difference with
> > > this error. This is
> > > one of our more complex SQR reports, with about 9000
> > > lines of code.
> > >
> > > Thanks for any suggestions that might help to
> > > resolve this problem.
> > >
> > > Chris Shelton
> > > Indiana University
> > >
> > > On Fri, 17 Mar 2000, Neal, Jerry wrote:
> > >
> > > > Hello,
> > > >
> > > > I am getting err. 004729 when trying to run an
> > > sqr report. I have 110 sql
> > > > statements in the report. I get the error right
> > > away
> > > > with no other error messages. Any help would be
> > > greatly appreciated.
> > > >
> > > > The version: SQR/4.3.4/IBM RS6000/AIX 4.2.1/Oracle
> > > 7.3.4
> > > >
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Talk to your friends online with Yahoo! Messenger.
> > http://im.yahoo.com
> >
> >
>
----------------------------------------------------------------------
Ray Ontko rayo@ontko.com Phone 1.765.935.4283 Fax 1.765.962.9788
Ray Ontko & Co. Software Consulting Services http://www.ontko.com/