Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Michael
About
- Username
- Michael
- Joined
- Visits
- 165
- Last Active
- Roles
- Member
Comments
-
I've had mixed results with Fix_LH I have a workaround. Thanks again for your input!
-
No, the SYSREPOSWINEXES record is there and I can run it. But I was hoping to be able to call the function in code.
-
Thanks Barry. Was hoping to do it programagically. It's available in OI9.4, but I can't find the documentation, and my Works is expired. No worries.. I can do it manually from the Database Mgr. Thanks!
-
Thanks for the help. I got a workaround
-
Ok.. my bad The tool tip just shows Rti_Set_Sizelock (CtrlEntId, Method, Param1, etc.) Nothing specific for the routine. I'd imagine the params would at least involve the table name and the sizelock flag. I guess I can trial-and-error if nothin…
-
So if I edit the SYSOBJ record, I hit Ctrl+T and nothing happens. What am I doing wrong?
-
The object code is in SYSOBJ, but we have no source code. I've not used the SRP Editor much. Does it work if there's no source code? The program isn't invoked anywhere in the system.
-
Still using OI9.4. So if the reconnect is part of OI10, it's a no-go. There's no obvious reason for the loss of network connection and nothing in any logs. Thanks for looking into it.
-
Actually using UD5.2. But the interruption is long enough to crash the program. And once it crashes, OI is totally inoperable.
-
Removed and it works. As expected.
-
Haven't done that yet. Guess I'll have to. Weird that it's ok in other environments tho. Thanks.
-
Ctrl-R and Ctrl-O both work fine.
-
Again, the MFS is Only on the SYSPROCS table, so I have no idea why it's doing this for other table searches. The other weird thing is that the identical MFS is on SYSPROCS in a test environments, and we're not seeing any problems. Trying the Ctrl…
-
I have the SYSPROCS_MFS installed on the SYSPROCS table. If someone tries to delete a source code record, from TCL or the Repository, it is blocked successfully. I never use the SRP editor. Those who do, and are using the Table Search, can no lon…
-
The plot thickens a little more. I put an MFS on SYSPROCS to prevent a delete, and it works pretty much as intended. The only problem now is that the SRP Search from the SRP Editor doesn't work any more. It's not returning the search results as b…
-
Not really but it's ok. Doing something else. Thanks for the help!
-
I would have thought that simple recompiling would have set up the SYREPOS pointers and such. Just trying it before I get further down the rabbit hole.
-
I agree about the risky part. So I put the MFS on the SYSPROCS table, and it mostly works. The delete is blocked, and the source and object code are still there. The program will still run. All good. If the user happens to delete the entity fro…
-
So I wrote the MFS and it works to prevent deletion in SYSPROCS. But if someone deletes from the OI main window, it leave the SYSPROCS record but deletes the rest and it's no longer considered a "stored procedure." To make it work again, one would…
-
Thanks anyway, sir
-
I'm definitely open to better!
-
Got it. But the authorities want to lock it down. Do I need to just write an MFS to block deletes?
-
The problem isn't GFE's. I need to compress the tables. I'm archiving 20+ years of data and the tables will need compressing badly. They actually already do.
-
Thanks Jared.. If I can get it working, can it be run while the tables are in use? Other option is to run RTI_REMAKETABLE, which will Not work while in use. Thanks!
-
So trying out the theory.. Fix_LH doesn't seem to work at all. It returns an error code of FS. Anyone run into this? Is there a workaround? Thanks!
-
Back gnawing on this bone. I'm developing a process to archive or purge a lot of data (20 years' worth). The purge will not be a problem; but I know afterward the tables purged will be "flabby" (lots of wasted space). Plan A was to use RTI_Rema…
-
Thank you sir! Sprezz was my next stop, but thanks for the direction.
-
Thanks Don.. Do you know how the Writes would be coded? Would table handles, etc. still be the same? I'm sure we've all done MFS's out the wazoo, but this is new ground for me.
-
Thanks. I think it's a non-issue for now. RTI_LOCK_OWNER doesn't work at all. In fact it abends OI altogether. Anyone have a workaround? Again, off-topic: the client has upgraded several of the workstations to Win10. OI still "runs", but more…
-
Actually RTI_Lock_Owner doesn't seem to work now. Quick off-topic question: We started getting a msg FS291: List over 64k bytes in BTREE.SUB operations or RELATER routines I thought the 64k issues were a thing of the past? Is this just a hold…