>You need to check you facts about VFP not having service packs since 5.0.

You need to read the message right :)

>From what I recall 6.0 had 4 or 5 service packs.
>7.0 had one (not sure if there were 2 or not)
>8.0 has not had one yet but I'm sure it will

I was talking about the database not the application side. You don't have to apply a servicepack to the database since VFP 5.0 (VFP 3.0 stored procedures have to be recompiled to work properly under a higher version). The application side service packs you'd have to apply regardless of the used strategy (one, two or n-Tier)

>As for planning about scalability this is like developing applications for single user first then changing to multi user. We built all of our single user apps as multi user whether or not the client asked or not. Why not plan for it now.

I'm sure, most of us do. However, might be less easy than it seams. For example if you look at transactional processes (like invoicing), you'd better check what can go wrong when two people at the same time try to start the same or simular transactional process involving overlapping data. Also what should happen when two users are modifying the same buffered record at the same time. Last save wins ? What happened in your audit trail ? That's of course a decision to make depending on the business. In the case of depending on business rules implemented in the application or business layer rather on triggers in the database layer, might leave the database in an inconsistent state because that layer did validate the data relying on the OLDVALues rather than on the actual values (EVAL()) in the database.

Making an application multi user for just viewing data is easy, making it waterproof for writing data is a total different matter. I'm not too confident of what happens when I take my cheap accounting software based on MSDE migrate it to SQL and run it in a multi user environment with 30 users, because it was not designed that way.

The problem is the assumption that if you design an application as multi user and test and introduce it as single user you do not have any problems when upsizing. you'd probably not be aware of (potential) multiuser problems in your software as described above.


>SQL/MSDE does not complicate development at all. As a matter of fact I think it simplifies it. We have an application that runs in more than 35 sites world wide. To run the applicatoin we just change our IP address in oour database list table and we can run the application over the wire just like we were there. No pcanywhere, no terminal service just the plain old TCP IP network we have. Try this with VFP. We did foxpro apps over a T1 over 10 years ago and it was not the greatest pefformance in the world. As a matter of fact it was pretty bad. I cant imagine that this has changed.

Absolutely right. Server based databases do have far better bandwidth usage than file server databases. However in the above you don't talk about development, but about maintainance. Also note that in your case you do have access to database trough the internet. With most of my clients this is not possible since the data could be real sensitive and only a few people might review the data. For security reasons the database is not reachable through the internet at all or the firewall blocks the port.

>SQL also has features that cannot be repliacated with VFP. We talk about scalability. How about redundancy. It is actually simple to create a replicated server with SQL server you can use replication or transaction log shipping. If your main server dies then you change a couple of settings and you are off to the races. How do you do this in VFP without extensive coding ? It sure does not come built in.

Al good arguments in favour of SQL-server, sure. But not all VFP programs do require this stuff.

Look I´m not against SQL-server. I´m using it in a few projects and it makes sense there. SQL-server has great features that you cannot (easely) create in VFP applications (but for data munging a VFP solution is far superiour). However, i´m not going to use MSDE for potential scalability reasons while there is no reason I could not program it in a VFP database with views or CA´s. When the time comes to upsize, we´ll do a bit of work to do this stuff. The client will understand that with upsizing additional work has to be done, and will gladly pay for it.

Walter,