We are trying to develop a version release system which is tied back to our bug tracking system. To this end we want to somehow identify changes in Stored Procedures, Windows, Messages, Popups, etc. assoicated with the application that are tied to specific bugs. This is easy to do with Stored procedures by using a specific row in the SYSPROGS source record to identify the bugs that caused modifications to the code. We also keep a history dialog of the changes in the source as well

With other items and objects such as Windows, Messages and Popups it is not as straight forward. My idea is to use a distant row in the SYSREPOS records (e.g. row 100) for recording the bugs that caused these to change. And possibly a history dialog similar to what we are doing in SYSPROCS.

I realize that SYSREPOS is the heart of the system and if this gets messed up we have serious problems. Besides this caution, is there any other reason why we could not edit and save SYSREPOS records for this purpose.

Or is there some compelling reason why we should not do it this way? (For example, such as if when the object is complied the SYSREPOS record is cleared and reentered. =] PS: I don't know if this really happens, I am just hypothesizing.)

Tom,

Why don't you use the Description column (Field 28) in the SYSREPOS record? You can use the Repository() SETDESCRIPTION/GETDESCRIPTION to manage this programmatically.

[email protected]

SRP Computer Solutions, Inc.

Tom,

You could also use the SYSENV table and establish a log using say a multipart key DebugLog*AppID containing information.

We actually prefer to use a different field so that the description could contain more meaningfull descriptive text. Our choice was KEYWORD (Field 17).

The Sprezzatura Group

World Leaders in all things RevSoft

View this thread on the Works forum...