can anyone tell me how to get a login id as part of a table reference
Darren Reely
darren.reely@latticesemi.com
Mon, 07 Mar 2005 12:54:59 -0800
Brian,
First let me say this sounds vaguely familiar. In fact I'm sure I've
done this using Powerhouse a long long time ago.
Second, substring searches (beyond the simple STRING@) using Powerhouse
are terrible. They are so slow I consider the ability as crippled. But I
may have a helping solution for this particular case.
Consider the CACHE option. It has some limits like only being able to
reference up to 255 records. But perhaps this will work for you.
If I were you I'd consider using a common table. This has an advantage
that the developers now and in the future will not have to remember your
special table per user hack and the rules for using it. A disadvantage
is that the screen will be responsible for keeping the table clean.
The table would have a repeating key to identify which screen process
owns each row. Something like userid, process id and timestamp which
would allow for multiple connections by one user and multiple users. You
would create this key for each new search. To remove stale data, you'd
call a special routine previous to any new searchs and in the EXIT
procedure before leaving the screen. Perhaps a nightly routine would be
used to remove old data that was not removed for some reason, such as a
user disconnecting from a PC window.
You can add data to the table via Powerhouse code or a callable Oracle
procedure. Since your performing substring searches, I prefer the Oracle
solution which I've found is much faster. You would however have to
convert the usual PH search string into something Oracle can handle.
Possibly a special cursor could help the Powerhouse search speed. Either
way, you'd perform this action in the POSTPATH procedure there by having
the data ready for the FIND procedures.
Once the temporary data has been set up in the POSTPATH procedure, your
FIND procedures should work against that table as you'd expect for any
table.
Managing your row id could have a kink. What if the original data has
changed, removed or appended? I'd build an appropriate key to that data
into the temporary table and link to the original for display and
possible editing. I don't see a need for sequence.nextval stuff. Simply
create a counter starting at 1 and increment it for each record written
to the temporary table.
If the row id needs to be in a sort order by some other data value,
simply fetching the data in that order should do the trick.
As for my previous suggestion. Heed Peter's warning. I seem to remember
something about this during a past review of some of the PH documentation.
You have a nice challenge. Good luck.
Darren