can anyone tell me how to get a login id as part of a table reference
brian_matthewsbrian matthews
brian_matthews_bmw@hotmail.com
Mon, 07 Mar 2005 21:26:41 +0000
many thanks for the feedback on the approach to the problem, and I will
probably get back on this subject at some point, but I am primarily
interested in automatic database authentication at this time.
The Oracle ops$ approach is looking great at the moment :) along with server
login database authentication for SQL server.
regards Bri,
>From: Darren Reely <darren.reely@latticesemi.com>
>To: brian_matthewsbrian matthews <brian_matthews_bmw@hotmail.com>,
>powerh-l@lists.sowder.com
>Subject: Re: can anyone tell me how to get a login id as part of a table
>reference
>Date: 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
>= = = = = = = = = = = = = = = = = = = = = = = = = = = =
>Mailing list: powerh-l@lists.sowder.com
>Subscribe: "subscribe" in message body to powerh-l-request@lists.sowder.com
>Unsubscribe: "unsubscribe <password>" in message body to
>powerh-l-request@lists.sowder.com
>http://lists.sowder.com/mailman/listinfo/powerh-l
>This list is closed, thus to post to the list you must be a subscriber.
_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger