Hi Bob,

>You just can't have it both ways... you can't say... VFP with DBF's is more flexable, and then go on and say how you can solve problems that using SQL overcomes in VFP by using some external plumbing which only partially solves the problem and introduces much more of its own.

I'm not sure what you're saying here.

I think we are not comparing the right thing. I don't say VFP with DBFs is more flexible, but rather an implementation with the VFP database engine is more flexible. I think it gets down to: you can create more flexible solutions with a VFP database engine. That the native storage format is DBF does not matter that much. VFPs database engine is a very flexible tool that can indeed use DBF files, but also do magic with cursor that might be feed from other datasources like SQL server, but also from XML from other tiers etc.

>>Again this depends on the location of the tier you're running. Of the tier

>Once again, you can't talk about 'simple deployment' then talk about using nTier, DCOM, etc.

We differ in this opinion I think.

>Bottom line, a traditional monolitic VFP app using DBF's on a file server is more prone to corruption and integrity loss than a traditional 2-tier client server app.

True, but I don't care if I encounter such situation once a year. However I do want to avoid the complexity and additional support that comes with (traditional) client/server applications. To me the theoretical problem less Atimicity and Durability is not enough. I can handle those situation quite simple.

>Yes, their are 'things' you can do to eliminate these problems, but they are all more complex than just moving to a true database server as your data store. Once you tie your app to these complex windows servcies, you loose the flexibilitys. Items like how you say single folder deployment, etc.

Bob, I already said, that THOUGH IT IS NOT COMMON PROACTISE YOU CAN. And yes you can do a deployment of an application in a zipfile if you don't use components that need to be registered if they are not already. Some of my clients run three or four of my products, all with the same support files. I can install a second, third and fourth product indeed by just installing a zipfile. Even if it was not the case I can do it by installing it in a folder, the setup included and the setup runs whenever the user starts the application for the first time. Not difficult. With a C/S application you still have to install the database somehow.

>>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.

>Buffering and transactions are STILL controlled at the client... so, if the client fails you loose the atmoicity of the transaction and thereby your data integrity.

Not neccesarily. It is about the time that is needed to write the data back to the files. If a whole transaction takes 1 second and only .1 seconds is needed to write the files there theorectically is a 10% chance of data integrity loss during that transaction. Even then: what does it mean. I've got a few hundred users using my products each day and never had to solve such problem in the last four years. We might be debating a academical question that might not have any value in the real world given the nature of a specific application.

>>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.

>So, because you can fix something, it's ok that it breaks all the time? Is that what you auto mechanic tells you.

You're talking like if DBFs should not be used for database application over a network. This way beyond me. Like I said, I did never had any report from my clients of such thing being the case. Set up your application right and you'll have a minimum amount of problems. I certainly object to the phrase "it's ok that it breaks all the time." because that is a thing that would not happen in the real world unless there are some serious problems elsewhere.


>Ok, once again, kludges and not normal out of the box stuff. Once again, SQL server gives you this kind of stuff for free... no kludging.

I don't know if this is a kludge. The solution, depending in how much security your need is only about 20 lines of code. How can this be a kludge? No, of course going through the backup options in the database server each time you install the thing is a time saver!?

>>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.
>
>HOW? I want to run my Crystal Report, what 'server' is there. See, when you loose VFP, DBF's just become a bunch of files. However, when you connect to a SQL Server database with other tools, you still have the full functionality of the SQL Server doing all it's jobs. That's what I mean by conectibility.

Deploying a VFP application over a WAN where the DBF is going to travel the network is never a good solution. There are much better solutions to that. Indeed running a SQL server is one. Using remote control like Terminal Server is another maybe even better one. For forensic stuff like maintenaince or adhoc things like adhoc queries, you might be able to do that if you've got or can create the right conditions.

>If if if if if... once again, wheres the flexability... you can run ANY query against SQL over a slow link and the query runs at full speed, on the server, and returns your results. No if's to deal with.

Don't take this as a general rule either. If you've got a complex query with lots of joins creating a larger resultset than the base data from which it was generated it might pay of to use the DBF way of running the query. Of course those circumstances are very specific, but they can be found esspecially in reporting modules. Just load the core data (from a DBF or SQL server) and mung it on the client.

In either case a Remote control solution like Terminal Services wins when we talk about performance.

>>>>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.

>If's your 'but' I have a problem with. VFP is not always the more efficient and optimal choice.

I never said that, nor did I want to imply that. Again my message is that there are cases where a VFP solution (with its local database engine) is a far more solid and flexible solution. Esspecially in applications where a lot of meta data has to be processed. You certainly do not want to let the SQL server do that, because it is too slow in general because it has to travel the network again. You can't beat the performance of local data to be processed and used locally.

>>If you read that conclusion from my messages than you really have got the wrong message.

>Read the quote from your message again:

>>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.

Excuse me my english, but what I'm saying here that for a particular hierarchical or other record oriented problem, you might be able to solve it in SQL server, but it is not going to be as optimal as within VFP. I did not want to imply that EVERYTHING is done more efficiently within VFP. (how many times do I have to say this... sigh...) You're trying to read thing that I don't (want to) say.

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

>I'm not confused, I know the differences. I've worked with BOTH products, VFP since version 3.0 and SQL Server for about 4 years now.

>>Do you really want to scope this discussion to Microsoft SQL Server and VFP 8?
>
>Nope, Oracle has the same advantages over DBF's that SQL Server does too.

But might handle specific problems in a total different way. This is why I said I want to keep my comments about SQL server as general as possible.

Again you're mixing up technologies. SQL server processes and DBF don't compare. One is a datbase server, the other a storage format. How you can compare those two is beyond me. Say if I was able to create a SQL server with VFP and clients can connect to it like SQL server, then your argument fall apart.

Your argument is about accessing data in a ISAM way over a network or in a SET oriented way. Please make the proper comparison. I can put DBFs in a tier residing on the server where the data is stored. There goes your bandwith advantage.

Your real argument is about deploying monotologic apps using DBF stored on a network and compare this with a traditional C/S app. And then of course are throwing in factors as slow network performance and unreliability while in fact this might not be the case.

>ANSI SQL is a specification, SQL Server and Oracle are implementations. In the real world we work with the products not the specifications.
>
>>I never said that VFP is the answer too all questions.
>
>Yes you did, read what I quoted from your message aboe.

Like I said, I've stated this a million times before: "I do not say that VFP is the solution to all" but there a certain circumstances which might be far more than you think, where a VFP strategy (Using the local database) pays of tremendously.

My main focus on this is the local database engine, not so much of the DBF implementation and usage. You can load your data from SQL server and datamung it locally. It does not make sense to do this on the SQL server.

>>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:

>No doubt... but this was never about NOT using VFP, only about using SQL Server vs. DBF's. I still use VFP on the client.

>Perhaps, but unless you are building a stamp collection ap for a hobbyist, in all mission critical business apps my evaluation has showed that the advantages SQL Server gives over .Dbfs without a cost in kludges or code or COM/COM+ stuff, recommends SQL Server over DBF's. That does mean a project couldn't be done with DBF's. We still have many customers running our Payroll/HR app which is written in FoxPro 2.6a using DBF's. However, they do see alot more corruption, need to reindex, orphan records etc than our SQL customers do.

How fair to compare a FPW 2.6 a app with a VFP app with buffering and transactions. I dont'draw the same conclusion as you do. My market seems to be a lot different than your. If you understand my business of having a few product deployed of many sites where there are not the right conditions to make a SQL server profitable (Licensing, Installing, Database Administrator, Troubleshooting) you would talk very differently I think. IOW: In most cases I can't sell a SQL server based product. And that is my real world.

Also you seem to totally ignore the world of data driven applications where a lot of fast data processing power is needed on the client.

Walter,








>I agree with you the VFP is GREAT, but I also feel SQL Server is great too, and the two togther are awesome!
>
>Although I also belive you can create just as good of an app with .Net, better if it is a web app.
>
>BOb