Microsoft implemented the "Virtual Store" concept in Vista. In days of old, it was common practice for apps to read/write configuration and ini files, etc. using the same folder where the app was installed... and this was typically C:\Program Files. Later on, when security was tightened in Windows, this practice would no longer work unless the user had admin rights. To prevent apps from crashing while protecting unauthorized changes, Windows was enhanced to intercept attempts to write into protected folders and re-directs the activity to the user's Virtual Store. Read attempts by unauthorized users into protected folders are automatically read from the Virtual Store if the file exists there. So, once written there, that's where the real file resides.
This is all well and good, and I have no doubt that a Vista engineering team within Microsoft patted themselves on the back for their ingenuity. The deception falls apart, however, when an admin user makes a legitimate change to what they believe is the "real" file residing in C:\Program Files... the non-admin user will never see the updated file because Windows always gives them the non-updated version that resides in their Virtual Store.
As Kevin correctly suggests, the fix is to stop reading and writing files from the app's protected installation folder.
You say: "there is another copy somewhere on there C drive, but we are unable to locate it. We know it exists just that we do not know where it is. There maybe some sort of security that is blocking a normal file search using the file explorer. I was looking for a function I can run from powerbuilder that could give me the files location. "
Have you tried opening up a command prompt and doing:
cd \
dir fileIamLookingFor.* /s
I've stopped using the search of windows explorer a very long time ago. It's slow and not trustworthy.
regards
C:
cd \
dir fileIamLookingFor.* /s