Hi Naomi,

We have a 550+ table application written in VPM running in VFP tables and in SQL, same code, at over 100 sites. Now, to get there, we worked with the framework for years, adding and fixing, and creating our own tools to work with it efficiently and effectively. An average of 3 FTE developers, only one of whom had previously used VFP (the others had used FP DOS) brought it to market (only 250 tables at the time) in less than 2 years.

Frameworks can't just be stepped into. They need to be made friends with, and that takes time, there are rough spots, and persistence and commitment are required. You have been placed in a very tough spot, expected to do what an experienced VPM developer might have a challenge pulling off. The things you mention about how VPM works are based on what works (for the most part; some of it we cleaned up along the way -- but the version you're using has a bunch of our fixes, because we gave them to ProMatrix gratis to use in the product, although not all of them got used). I have enough proof from our project, and from other small (50 table) ones I've done myself, and those of intermediate size on which I've consulted, to say without hesitation that the problem isn't the framework. And of course it's not your ability in VFP. You just can't become good friends with any framework without putting in some time. One of the two brightest persons I know became friends with VPM in 6 months, and expert in it in 18 months (he would probably say sooner, and if so, he might be right <s>). Double that for the rest of us, and that would be with mentoring for the first year.

VPM itself has nothing to do with the other developer's decision to use meaningful PK's: the framework has a system for creating surrogate PK's for either VFP tables or SQL tables. There is no accounting for bad taste. <s>

I don't envy you your challenge in this.

Good luck,

Hank

>Hi everybody,
>
>I'm working with the existing application. The more I look at it, the more I don't understand.
>
>1. There are millions of public variables in all the places
>
>2. Almost each form tries to switch datasession using SET DATASESSION command
>
>3. There is lots of code in all the places (Init, Load, Activate, Show, valid of textboxes / gotfocus, etc.)
>
>4. The code uses SET FILTER command lots of times
>
>5. In one of the table we have about 20 or more indexes. About half of them use the exact same index expression, but different tag name.
>
>6. The application is based on the VPM framework
>
>7. The database is completely de-normalized / relations are based on names.
>
>----------------------------------------------------------------------------------------------------------
>No wonder this application behaves unpredictable. However, how I'm supposed to fix problems / bugs with it? If I try to change one little piece of code, I would not know what is affected - results of my change could be.
>
>BTW, when I ran this application in VPME and checked developer's info, I found the name of the developer. I searched VPM Newsgroup and found several of his questions there few years ago. The questions all seem to be OK.
>
>I'm just wondering how such applications can be written and more importantly - maintained later.