MFS and SYSPROCS (OpenInsight 32-Bit)
At 20 APR 2005 06:44:12PM Tom Savell wrote:
Wrote a MFS that I am attaching to the SYSPROCS table and can't get it to work when opening a stproc from system editor. It does however work by writing a subroutine to open and read sysprocs. Is it possible system editor is calling rtp57 directly? Any thoughts/ideas on how to get the mfs to work from system editor?
At 20 APR 2005 10:24PM dsig _at_ sigafoos.org wrote:
I beleive this came up a really long time ago .. and yes if memory serves the System Editor is not quite .. err legit
What happens with the NEW editor?
dsig _at_ sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"
David Tod Sigafoos ~ SigSolutions
At 21 APR 2005 04:19AM support@sprezzatura.com wrote:
As far as I know, the system editor gets the record using the repository ACCESS method. What happens when you try that from code?
If that doesn't work, then I think you've set the system up wrong, since the repository caches all the file handles for the repository files in a common.
The system always loads up SYSPROG.DBT first, because it needs to get all the file information to validate and get the account, then it goes and loads up the application DBT. But, because these handles are already cached, it uses the handles from SYSPROG.DBT.
So, my guess is that you've put the MFS on, it's sitting in REVMEDIA, so it all looks OK, but it's not in SYSPROG.DBT and therefore not loaded into the repository handle cache.
support@sprezzatura.com
The Sprezzatura Group Web Site
World Leaders in all things RevSoft
At 21 APR 2005 11:07AM dsig _at_ sigafoos.org wrote:
As i mentioned .. a long time ago there was a system tool which bypassed this .. but of course you are also correct in problems with the DBT 'remembering' ..
Wish it wasn't there .. was okay when disks were slow and loading took time .. but attaching is so fast any more that that is less of a problem.
Down with dbt .. down with UD .. up with Volume Pointers .. UP with file systems that are compatible
dsig _at_ sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"
David Tod Sigafoos ~ SigSolutions
At 22 APR 2005 05:02AM support@sprezzatura.com wrote:
In one of our apps, we just attach everything on create of the main window anyway. Doesn't really do any harm.
I don't find DBTs to be an problem, but it does create strange problems with system files getting cached.
support@sprezzatura.com
The Sprezzatura Group Web Site
World Leaders in all things RevSoft
At 22 APR 2005 10:03AM dsig _at_ sigafoos.org wrote:
.. no not a problem like .. oh dear i have a flat tire
A problem in that it is not needed .. and just another hidden bit that people don't learn about until it bites them in the ..
dsig _at_ sigafoos.org.com onmouseover=window.status=the new revelation technology .. a refreshing change;return(true)"
David Tod Sigafoos ~ SigSolutions
At 22 APR 2005 04:47PM Tom Savell wrote:
I got it to work somewhat, I think, but am bein thrown to the debugger with "ENG0010: Rev_Loadrec Line 1 Variable has not been assigned a value."
At 25 APR 2005 04:24AM Richard Guise wrote:
Hear, Hear!
In the early days of OI we had problems with the DBTs in deployed apps getting out of synch when system mods were made (e.g. changing indexing, MFS, etc.). Hence we copy SYSPROG.DBT for each app but, as suggested, attach app's files in CREATE event on our first (menu) screen.
Our own modified version of RDKMODULEINSTALL has calls to update DBT removed (actually optional parameter defaulting to not update).
This has proved simple and reliable. Furthermore we have a couple of sites which have multiple similar databases for their different clients. We can simply detach one and attach another at the touch of a button.
At 26 APR 2005 08:40AM Bob Carten wrote:
Some repository methods use REPOS.BFS, which calls RTP57 directly.