In our application we have a stored procedure called WARN_LENGTH. It's a simple stored procedure that checks for maximum length exceeded and is used throughout the app. But, at one of our user's site, we're getting breaks to the debugger saying that WARN_LENGTH couldn't be found. We checked SYSREPOS and SYSOBJ. It's in SYSREPOS, but it's not in SYSOBJ! This is a runtime version.

Any way we can fix this so that the it finds WARN_LENGTH.

Why cant you do do an RDK Deployment to extract that Stored Proceedure executable from development and then do and RDKInstall on the runtime. If you havnt established any process for RDKInstall on the runtime just get the runtime going and then separately execute dwb.exe from the Run command ie

D:\RevSoft\OI402\DWB.exe /AP=APNAME /UN=APAUTHOR /PW=PASSWORD

This bring up the editor. Then Run

RUN RDKINSTALL "PATH_TO_UPGRADE"

BTW, to loose the Stored proceedure suggests possible corruption of repository. Might want to do a LH Verify?.

Richard

We've tried running an RDK into it, and that didn't work. We also checked both SYSREPOS and SYSOBJ for GFE's and neither one has GFE's. Any other suggestions?

Have you confirmed that the stored proceedure is being extracted into the SYSUPGRADE table?

By this I mean attatch the RDK Deploy volume and inspect the record keys in SYSUPGRADE. You should find two keys in form -

SYSOBJ/$MY_STORED_PROCEEDURE*MY_APPLICATION

SYSREPOS/MY_APPLICATION*STPROCEXEMY_STORED_PROCEEDURE The records respectively are the stored proceedure and the SYSREPOS pointer record for the stored proceedure. If the above is intact, the next suggestion is to assetain if the repository indexes on the runtime are corrupt and need clearing, rebuilding. Richard </QUOTE> —- === At 10 JUN 2002 09:19PM Scott, LMS wrote: === <QUOTE>This reads like something may have gone wrong with the app name. Ie you build something in SYSPROGS and think it is in MYAPP. But this doesn't really explain the sysrepos thing. the evil hack version - using system editor: Please check the appropriate names very carefully. I haven't tested copying out of sysrepos. In fact I'd probably prefer that you copy the missing exe from your source app stprocexe to a dos file (copy_row_to_os) and copy it back into the broken stprocexe file from the dos file RUN COPY_ROW "SYSREPOS", "MY_APPLICATION*STPROCEXEWARN_LENGTH", "SYSOBJ", "$WARN_LENGTH*MY_APPLICATION", 1

This is similar what I did when I was having trouble with check in. A search on "apprentice granny" finds that thread.

In case you didn't know it is possible to run system editor without the development copy of OI, make a shortcut to dwb.exe in your OI directory. You need to open the main application first, then fire up the dwb.exe /AP=thingy /UN=thingy

good luck

Scott,LMS

View this thread on the forum...