Cache?

[GirlNet]

Hi All!

We have 2 databases all using the same custom code path. I changed some custom code and it works fine in one database - but not as expected in another. What was changed was a label and some math. I see both the label and math changes in one database but only see the label changes - but not the math in the other.

Is it possible that some shared memory/caching is going on? Has anyone seen this before.

 

[kishorchari]

First try it from different PC.

I take it you are using GUI or CHUI interface , Cache doesnt come in to picture.

Now if the program PROPATH is not same you can get this issue.

 

[GirlNet]

The propath for the custom dir is first in line in both databases. Do you think that compiling against both databases is the issue? If I have one custom directory with 2 databases. Do I need to compile against both databases even though the file name/path is the same?

Someone suggested that . . . .is it possible?

 

[kishorchari]

Try this look for the .r. If more than one copy exist then delete them, And recompile the program. Try it after placing it in right folder.

 

[TomBascom]

r-code is cached if the -q session startup parameter is in use. You can clear the r-code cache by stopping and restarting your session.

Most production environments use -q. It is better for performance and you are (hopefully) not updating production code mid-day anyway.

It is also possible that you are running with r-code in a prolib. Usually there would be something.pl in your PROPATH if that is the case.

 

[GirlNet]

Thanks TomBascom. That does help. I'm just really baffled here. It's not just 1 program but a few. Most of the custom programs were not written by me - and I'm new to this - so it's still a little fuzzy.

But . . . how can a custom application act differently based on the database. The menu item is using the same program - but one will allow a shipper to be generated when no items have been picked and the other prints an exception notice when no items have been picked.

I've looked for flags and everything is exactly the same! I've gone menu by menu and everything is using the same code. I'm really baffled here.

 

[GirlNet]

It is also possible that you are running with r-code in a prolib. Usually there would be something.pl in your PROPATH if that is the case.

I looked - no r-code. Lots of *.pl in the propath though.

 

[GirlNet]

Try this look for the .r. If more than one copy exist then delete them, And recompile the program. Try it after placing it in right folder.

Nope - only 1 copy. Plus only 1 folder for r code. That would be \custom\us\xx

 

[TomBascom]

It sounds to me like you are using progress libraries. You have .pl files so someone, at some point, has set them up and put your r-code into them. You should read about the PROLIB command to learn how to work with them and find out what is in them.

I'm guessing that there must be some scripts or a procedure to follow when you make changes to get your changes put into the proper library.

As for why two systems behave differently... something is different. PROPATH, library contents, code differences, parameter settings... something.

 

[kishorchari]

Can we have a small query written, compiled, attached to Menus & Tested?

Tom, QAD users dont use much of PROGRESS functionality e.g. Library etc. It is something simple that is going wrong here, we have to find it the hard way.

 

[TomBascom]

GirlNet says that she has *.pl files in her path. Those are Progress libraries. Someone put them there and there is a really good chance that that is why her r-code is being ignored. A different, older, version is in the library and is being found first.

You'd be surprised. Lots of QAD sites do use interesting features. You just have to get over the FUD.

 

[sanjus]

Can you kindly specify you environment? QAD Version, Progress Version, O/S, UI: GUI, ChUI, .NetUI, desktop UI?

1. Being 2 QAD environments, you don't need to compile against the 2 environments as QAD startup parameter file has a logical db name (qaddb).

2. Is the program in which the changes are done the main program or sub-program.

3. Can you put some debug messages in the beginning of this program to see if this is the one that's being actually called from db1/db2?

4. As Tom mentioned, it could be a library issue.

5. The label changes can come from the Label Detail Maintenance instead of the program. So it might be that the 2nd Db is not at all calling the 2nd program but some routines from the library, if prolib is being used.