Re: Re: Set Isolation

As far as I remember you can use a stored procedure to retrieve data to crystal reports. If the stored procedure has parameters Crystal ask for them passes to the sp and execute it. Can't you create a stored pocedure which do a set isiolation and with a cursor retrurns the data needed in the report? Chucho! -----Original Message----- From: "Markus Bschorer" <mb@worxbox.com> To: informix-list@iiug.org Date: Wed, 3 Mar 2004 14:10:38 +0100 Subject: Re: Set Isolation Hi Jonathan, sorry, but this does not work. It seems, that the stored Procedure will be executed wthin the SELECT-Statement. But the SELECT-Statement itself will be executed using the current isolation mode. And this is committed read. Do you have another idea? Bye Markus "Jonathan Leffler" <jleffler@earthlink.net> schrieb im Newsbeitrag news:hHe1c.19227$aT1.9757@newsread1.news.pas.earthlink.net... > Markus Bschorer wrote: > > IDS 9.4, RH9 > > > > we access some views in our database using Crystal Report in order to do > > some reporting. > > The problem is, that we have to access the database using the isolation > > level "dirty read". > > When accessing normal tables (not views), we could create a select-trigger > > on these tables. From these triggers, a stored procedure was called that > > sets the isolation level to dirty read. But there is no way to create a > > select-trigger on a view. > > Crystal-Reports only allows us to define a select-statement on tables or > > views, but not to execute some sql-statements before executing the first > > select. > > > > Does anybody has an idea how to handle this? > > Does Crystal allow you to generate temp tables en route, like ACE > does? If so, you could consider creating an empty temp table which > you subsequently ignore, using a stored procedure which primarily sets > the isolation and coincidentally returns a result. Maybe... > > So, if that won't work - probably not - you can still think about > whether a 'cursory' procedure like this can be used: > > CREATE PROCEDURE setisolation(i INTEGER) RETURNING INTEGER; > SET ISOLATION TO DIRTY READ;> RETURN i; > END PROCEDURE; > > ...the following has not been near an instance of IDS... > ...assume syntax errors are present! > > SELECT * > FROM WhereEver, > TABLE(SET(EXECUTE PROCEDURE setisolation(0) AS peculiar))> > The idea is that the procedure is executed fairly early - probably - > and generates a single row of data, so that the cross-product of one > row with all the other rows is the same answer as you thought of in > the first place, give or take the peculiar column. > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/ > Jean Sagi jeansagi@myrealbox.com jeansagi@netscape.net sending to informix-list