What I need is something that compares the tables to what is out in the application directory. Is there anything in Baan that might give me something along these lines?

The reason for this is because we have found that the tables say the script is in the B40 standard VRC. Yet explode6.1 will tell me the object is another VRC. In these cases the object actually exists in this other VRC. We have several of these situations - plus I think some consultants along the way dropped some library objects into our production VRC. Probably this was done at conversion - years ago. I need a way to identify these problem objects and so I can clean them up. If there is nothing then I will write something - just looking for a head start.

Be careful what you ask for! What you are describing is a normal occurance. If an function (include) file gets changed, there is a session (ttadv2230m000 in Baan IV) whith an option to compile Scripts/Libraries of Previous VRC's where functions in new VRC. This will cause the problem you are describing.

The utility you desire will need to look at all functions where used to compare the objects in the VRC.

BTW, there is also an option to compile all scripts/libraries and place them in the current VRC. This was thought to better performace so the bshell did not have to search down the VRC tree structure.

Since we do not own source compiling Baan sessions is usually out of the question. We do not have the includes. We use option 1 of the session you mention. Sounds like I am going to have to write something. The only things I want to see in our production layer are those things that we have actually changed or modified. Needless to say this will not delete anything - the plan is to clean up things by hand.

Mark,

This indicates a misuse by someone with the global compiler (ttadv2230m000) with "All scripts" option.

You can find script/object info in - ttadv2539m000 - Objects by Program Script/Library.

If you want to write a correction program yourself then you have to use some of the tools functions/libraries -

search.path.object
long search.path.object( domain ttadv.cpac cpac fixed,
domain ttadv.vers vers fixed,
domain ttadv.rele rele fixed,
domain ttadv.cust cust fixed,
domain ttadv.cmod cmod fixed,
domain ttadv.cprs cprs fixed,
ref string path.object() )
from ttdllsrch_path
or

get.envpath
long get.envpath( domain ttadv.vers v, domain ttadv.rele r,
domain ttadv.cust c, domain ttadv.kord k,
domain ttadv.cpac p, domain ttadv.cmod m,
string s(18), string l(3), long vr,
ref string envpath() )
from ttdllenvpath
to get the report of mismatch scripts/objects.
You have to be much more careful if you want to write a auto-clean up tool.

Good Luck!

We have a patch from Baan on one of our components - Autotime. Our admin was told to install into our PRD vrc. That was a mistake. So what we did was create a new VRC in a test company. He then installed the patch at this level. At this point we started looking at the objects that were installed - tdilc4201 is one example. I have no table record pointing to the new VRC yet this object clearly exists in the UNIX directory structure. This was installed using the PMC tool. We ran into other problems, but this one bothers me the most. I also know at one time some consultants we used had access to source. They compiled and moved objects into various places - we have run into a couple of these over the years. We think we have it fixed, but we would like to automate the process of finding these irregularities.

By the way Baan is suppose to fix the Autotime patch to contain only those components that it really needs. We have no time frame for this. So one issue we have to deal with is determining which object we should really be running - the Autotime component or the A and D version in the update(patched) VRC. So much fun so little time. :)

I will look into the srch_path dll - if it works like explode6.1 then that will help in my coding efforts.

Thanks

Mark, You can also use - pathname() (http://www.baanboard.com/programmers_manual_baanerp_help_functions_directory_file_operations_pathname)

I once had asimilar problems with objects present on VRC's where they should not be. I wrote a UNIX shell script to go thru the VRC's and then check the table (thru qptool) for an entry to it; if the object was not mentioned in the corresponding table it would generate an alert with VRC/table/object information. I run the script on production and test and then used a diff on the results. The script did also the vice versa, and would check the tables for objects non existant, that would need a compilation of dump.
It's well worth the build work since you will use it quite often.

While the procedure I described earlier may not have been run at your site, Baan uses it internally. So when you install a patch, you may get objects that were changed because of a function (include), and will not get source as it has not changed from an earlier VRC, and it will not have an entry in the database. Every so often, like Baan4c4 Service Pack 4, Baan rolls up the previous VRC's so that all the source will once again be at a Service Pack level. I am not aware of any rollup since SP4, but it might be possible.

Interesting notes - thanks. In our case it was confusing because the objects were different sizes in the update VRC and the autotime object. We could not tell what we should be running - did we need the autotime version or not. Baan is suppose to address the issue, but it really does not help us right now. Sigh.