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

Sorry, I didn't mean to be rude. That was just my natural reaction to your comment that DCOM is 'simple'. I would have chuckled/laughed if we were having a face to face also.

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.

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

COM/DCOM/COM+... a rose by any other name...

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

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.

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


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

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

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.

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

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

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.

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

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.

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

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

Nope, Oracle has the same advantages over DBF's that SQL Server does too.

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.

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

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

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.

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