RCode-Info:Table-List

[MattKnowles]

I have been using rcode-info to identify tables that reference particular tables in order to give us an idea of how many files will need to be compiled following a DB change.

This works well on the server where all our routines connect directly to the DB and so the rcode contains a reference to the required table.

Unfortunately our client code is compiled against an empty copy of the DB and while it doesn't make reference to tables directly it does make extensive use of the 'define...like' command. This does not seem to figure in the rcode-info (correctly) but errors will occur if this code is not compiled after a DB change (client/server tables do not match error).

One method I can see is to compile...xref and look for any 'REFERENCE' entries but this will be slow for the thousands of routines we have.

Do any of you know of a quick way in which I can identify which procedures need to be compiled?

Many thanks,

Matt

 

[TomBascom]

Why not just compile everything?

 

[RealHeavyDude]

TomBascom + 1. IMHO not having something like a central build in place is the road to hell. As long as the code makes static references you might be able to figure it out some way. But, as soon as your code contains dynamic references neither RCODE-INFO nor XREF will help. Plus, database changes are not the only reason as to why you want to re-compile the code. Heavy Regards, RealHeavyDude.

 

[MattKnowles]

We have five to six thousand GUI routines that once compiled need to be distributed across a WAN to various developer sites across the UK. While the compile itself is not too painful the distribution itself can take well over an hour. This means that the downtime resulting in a 5 minute DB change can be considerable.

Therefore I have been tasked to find a way to target the compile more efficiently. The rcode-info:table-list method works well on our server code as all this has direct DB access. Our GUI code accesses the DBs via the AppServer and so the table references they make is via 'like' statements when defining temp-tables (we connect to an empty mirror DB when compiling). These statements don't create entries in the table-list and so can't be found via this method.

 

[j4n]

have you tried to compile everything against the old db, storing the RCODE-INFO:CRC-VALUE somewhere and then recompiling everything to check if the CRC-VALUE has changed?

 

[TomBascom]

j4n's idea might help you. But RHD is right -- counting on rcode-info in this day and age is a recipe for disaster.

But I would re-think the problem... rather than push the updates to developer sites I would come up with a way for them to recognize that they need a refresh and pull the update (which I would probably package as a prolib so that only one file need be transferred).

 

[GregTomkins]

What is a 'developer site' anyway?