Staging the new version to a test environment sounds like a plan. As Griff says, "white-box" knowledge of changes allows testing aiming to investigate whether these known changes affect you, but to know that you most likely meed white box knowledge about the VFP application, too. It's not clear to me, whether you actually have that insight in the VFP application or this is closed source to you.
You'll know a set of most important features of the VFP app you use and test along these features in order of descending importance, typically. Perhaps prioritizing tests, that are shortest.
I also have the feeling this isn't just about the upgrade of the Oracle Database itself, but the update of some main software like SAP. It's very likely something also deprecates and may already have been announced to deprecate long time ago and still the VFP app won't adapt automatically unless it's actively maintained by the vendor about checking such announcements not only of the Oracle RDBMS changes but also the data structure of the SAP or another software suite the VFP application based on. It's always a harder job to keep such a third party application working, if you're the vendor, as you don't control the roadmap of development.
You can get some whitebox knowledge by profiling what queries the VFP application uses or what stored procs it calls, if you have a profiling tool and can apply it. That'd also enable testing just the data access in a testsuite/script collecting the different queries, which are found in short/mid term profiling.
Bye, Olaf.
