Hi Bob,

>>You mean should not be ignored? A lot of these features are fairly simple to accomplish with a VFP solution also.

>>- Security can be reached by using COM/DCOM/COM+/remote control/ layers which shields the database from the user.

>HA HA HA! DCOM is "fairly simple".

Sorry Bob, but please don't get rude. You know I cannot stand that. I can get really irritated in my responses.

DCOM indeed is not an easy thing to use, though not impossible. AFAIK, this is the reason why it is overshadowed by COM+. I wanted to list a few technologies which are capable of hiding functionality and limits the user to access resources.

>>- integraty: I'm not sure what you mean by this. Examples please.

>Integrity. Example, write a process with VFP transaction, etc etc that runs for about 3 minutes... Start the process and then UNPLUG the network cable from the PC. Generally this will ruin your data intergrity, since the transaction is actually controled by the PC, not a server there really is no atomicity.

Again this depends on the location of the tier you're running. Of the tier is running on the server, there is no network plug between the process and the server. Also, I wanted to note that a transaction of 3 minutes is ridiculous. This is not how you would write a transactional system. Transaction should only last for a fraction of a second, and no longer than that. Transactions do have implications on the concurrency of a database system esspecially in a secure RDBMS systems where the isolationlevel is set to SERIALIZABLE. Then this transaction could block about every other QUERY on the server that is trying to access anything that overlaps the data in the transaction. which on itself causes a domino affect and causes a deadlock event on your server. In stead divide the problem into smaller transactions and commit them regulary.

Even when implementing this on a VFP based system over a network (note that I said that this is not wise to do), buffering and transactions to minimize the risk of corruption in this case, So even in the event of a lost network connection it does not per definition have to mean that your database is corrupted.

But you're quite right in the sence that though VFP supports transactions, it does not by all means support the A(tomicity) and D(urability) from the ACID properties that come with most server DBMSs (Though Durablity still seems to be a problem in most DBMSs).

>>- Maintainability: In what respect should a VFP solution not be maintainable ?

>If the above happened, what do you do?

I'm beginning to note, that with the strategy of using transactions, buffering and a good network this event should be rare, much more rare than the event of beeing called with a specific support call for a SQL server related issue.

Second, Even if the database is corrupted in the sense that the recordcounter is not in sync anymore, you can fix that quite easely. A reindex could just fix the index corruption. The unfinished transaction could be checked forensically, or by a programmed checking routine.

>Can you have automatic backs of DBF's while they are in use? SQL Server's low level of corruption makes the database easier to maintain.

Yes you can. You've to got to use a strategy that disallows (FLOCK) updates to certain tables when backing up or provide a mechanism that propagates the updates and deletes to the backup as well (comming to think of this, this would not be too difficult as well). But of course, this does not solve the problem. In SQL server a backup does not mean much if you don't have the transaction log. If you only backup the database once a day, this would also mean you've lost the work done during that day. You need the transaction log.

>>- connectability: In what sense. VFP databases are fairly open and easy to access ?

>Ok, try to connect over a 56kb WAN, and run a complex query against several multi-million row tables... Sure, it will work, you'll get your result in the morning... if the connection didn't dump!

Sorry, I can't see what this has to do with connectability. It is about network bandwith. Just run the query on the server instead as over the WAN. I don't see this has anything to do with SQL server versus DBF. You don't have to try to install the database on another networknode than the serverprocess either (if even possible). There is really no objection to run the query on the server.

I've done a lot of support trough a WAN, and I can tell there is a lot what you can do over a slow WAN connection as long as you know what you're doing. A complex query can be efficently run on a multi million table if:

- The query involves just a limited number of records
- The records can be efficiently located through an index.

>>I think you've read the wrong message. I never wanted to imply that a SQL server is not able to accomplish something, but its solution is by far not as optimal and efficient as the VFP one.
>
>I read exactally the above. You can't actually believe that VFP is the optimal and most efficient solution for EVERY problem? Is that what you really believe?

If you read that conclusion from my messages than you really have got the wrong message. DBFs are certainly NOT the most effictive solution to EVERY problem. However I've got the feeling that some persons up here try to put down the DBF technology as out dated, irrelevant, obsolete and thus something that should be avoided if you can.

The thing I try to outline here is that the DBF way of doing things actually can have advantages. There of course are another number of other issues that seem to be confused here. There is no technical reason why the implementation of a SQL database cannot be record oriented. However for efficient record oriented programming there is not much to find on current SQL database server implementations. With the xBase implmentations you generally have both a strong record oriented and set oriented approach which leads to the advantage that it is a stronger data munging tool.

Do not confuse VFPs DBF vs SQL Server with:
1. Set oriented vs Record oriented OR
2. Local remote data processing.

>>Also note that I try to keep this general and not to a specific SQL server implementation like MS SQLServer 2000, but more in a general sense that also applies to other Server RDMBS like oracle, DB2, Sybase etc. The examples I gave were ment to see what the SQL Server pros could come up with and my intention was to discuss the outcome in comparison to the VFP solution.
>
>Oh, that's conveinent, now you were talking about ANSI SQL (which isn't a database) but not SQL Server cause it actually has better ways to do things.

Do you really want to scope this discussion to Microsoft SQL Server and VFP 8? Not quite productive I would say. So if you and I or anyone else is deploying an application on a ORACLE, DB2, Sybase, Informix or even pre SQL server 2000 versions they should not be involved in this discussion ?

>You also say VFP is better cause you just copy it to a folder, then you talk about using DCOM for security, which is doable, but not simple.

Agreed.

>I'm not sure I know what we are really trying to decide... That VFP not only has it's place, but it is the best solution in ALL situations no matter what?

Again it is not just a matter of choosing between .VFP and another development tool. In this thread there are a number of issue intermixed which leads to confusion:

VFP vs .NET
The value of a local databaseengine
DBF vs a databaseserver
Local vs remote processing.

Only if you look at those items individually you're able to make up a clear picture, not in the chaotic way we are doing now.

I never said that VFP is the answer too all questions. The only thing I'm trying to say is that VFP has it place because in a high number of situations, because it has a number of characteristics that are very valuable in the database development world:

- Connectivity to a SQL server.
- a Local Database engine to do post processing of data.
- a rich DML of both SET and RECORD oriented functions.

Note that I don't exclude VFP and SQL server. They do have its place.
SQL indeed has advantages where scalability, security, ACID properties, a rich set of SET ORIENTED dml functions is an issue. But this does not mean we all should be running to implement a SQL server solution and after that just run to .NET because it has some significant disadvantages too. You'd better know what you're doing before you make up your mind.

And Yes, I have the opinion that the strenghts of the VFP localdatabase engine are undervalued by some persons who claim that SQL server is the way to do all your data processing. This is really unthoughfull and it does not prove to any knowledge about implementing data intensive applications.

I guess this is caused by the fact that there are many database applications written in languages that DO NOT HAVE a local database engine. These application are more or less forced to do all data processing on the server whether it is or not is the most efficent way of handling data. Further they don't seem to realize that they put significant constraints on the application design. I suspect there won't be many data driven applications written in those programming languages.

Only developers that know the luxury of using a local database engine and do have experience with a backend database like a SQL Server, do seem to realize this and are able to create more flexible database solutions. They generally are masters in massaging the data into any form they want and also minimize network trafic and server load also by doing many task locally and only use the SQL server as the data provider.

Walter,