Qdesign enhancement - Required Secondary file

Darren Reely - Lists devlists at reely.com
Wed Jun 6 16:30:10 CDT 2007


On Jun 6, 2007, at 12:51 PM, Deskin, Bob wrote:

> I understand that you'd like to use a common set of functions, but  
> we were there first :-)

LOL.


> Seriously, are there SQL functions that don't have PowerHouse  
> equivalents? Keep in mind that we're not using pure SQL but a  
> Cognos version of it. Our middleware must allow the functions and  
> then passes them on to the database.

Oracle's DECODE() comes to mind. In one case I had to use UNION to  
'TRICK' Quick into the result I was looking for. The cost & time of  
the transaction was much higher as a result.


> I'd like to make sure I understand the passed in values request.  
> Can you elaborate?

To not have to rewrite a screen twice, several screens I've  
maintained or written over the last several years have the ability to  
have a value(s) passed to them that automatically fetches the data  
when the passed values have content.

The case is that from a menu or other screen, the user may want to  
use a common screen. Calling from a menu we would not likely have a  
lookup value, but the user can supply one on the called screen.  
Calling from another data screen with content displayed, we could  
call the second screen with a value and have the data immediately  
displayed (and limited to that data). The second screen in question  
may just be a view only screen or a full fledged editing screen. That  
part isn't relevant.

In the input request procedure we would have some code something like  
this.

if NOT passedValue IS NULL  ::<<Another pet peeve, IS NOT NULL should  
be proper here.
then let path = 1
else
request ...

Then of course we need custom find procedures.


> As for the left hand functions, that's because of the way our  
> parser was designed (>25 years ago). A few years ago, we looked at  
> it again but found that it got confused if we allowed expressions  
> on the left. And at this point, we don't want to introduce  
> something new at that fundamental a level and risk stability.
>
> CSV is still on the table but don't hold your breath. One of the  
> reasons for the dearth of QUIZ enhancements is the prevalence of  
> reporting options from relational databases. Also, we are  
> constrained by the architecture.

Sounds to me like the architecture needs an update. ;)

The left hand function problem is a pain in the rare. Powerhouse is  
the only language I'm aware of with this limitation.

CSV is on my mind because of my experience with it this past year.

Here is a thought. If Cognos is not going to add to Quiz, they should  
give free developer licenses for ReportNet to their payed up clients.  
Start encouraging them to move to something more current and announce  
an end date for Quiz support.


> By the way, it's easy to output a pdf report in QUIZ for Windows.  
> Simply get hold of one of the pdf printer drivers, such as  
> PDFCreator at sourceforge.org, and use it in the string following  
> SET REPORT DEVICE PRINTER.

What percentage of Quiz developers use Windows?


Darren

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20070606/0a66d5b1/attachment.html


More information about the powerh-l mailing list