Menachem,

The larger point is that MS appears to ignore the needs and wishes of the masses, in favour of who-knows-what!!!???

My particular issue is *not* (repeat: not) a SQL-Server capability within VFP. It is a VFP-to-VFP communication capability which includes
1) Client passes SQL/View stmt and gets back record(s);
2) the 'server' end can handle several VFP clients simultaneously.

In other words, none of the power/security/etc of SQL Server.

I have been planning, ever since VFP6. was announced, to buy the *next* release of Visual Studio. Now it seems I will be waiting until at least September. And I just finished reading that SQL Server rel. 7 *may* be released next March (1999). These are prime examples of why it is my preference to try to restrict my stuff to as few independent products as possible.

By the way, I looked up ADO in VFP 5.x Help and came up dry. I wonder why???

Regards,

Jim N

>>Craig,
>>
>>But really, it is time *we* all stopped making excuses for MS and the VFP team and it is time for them to start speaking for themselves!
>>
>>Ya know, poor ol VFP has to kow-tow just to keep alive in MS. Poor ol VFP has to be a "good player" in Visual Studio. Poor ol VFP has to keep SQL-Server sales in mind when they think up things to leave out of the product. Poor ol VFP only has so much advertising budget. Poor ol VFP yadda-yadda-yadda!
>>
>>Well, some of us are POOR OL USERS! Some of US think it's time that WE MATTERED, at least some!
>>I am quite happy for VFP to be a "good player" in Visual Studio (or anywhere else) as long as VFP cares to be a "good player" for its USERS TOO.
>>
>>Just as VFP 5 didn't *really* deliver "server" support in the broadest sense (but only in a highly restrictive sense), so VFP 6 is now appearing to be less than "fully" MTS. What good does it do to go on fooling the USER community like this??? Sure, those of you who are full MS adherents argue that these are positive things and moving in the right direction and that all will be well one day.
>>But some of us have a little less patience, and we pay our bucks too! Bucks that have just as much value as yours.
>>
>>We can wait 'till hell freezes over before we see objectified menus or reports, but for some that's OK because its *probably* because Visual Studio is going to do something "generic" about them!
>>Look, I don't even particularly care about those two items myself, but lots and lots of USERS *DO*. Are they to wait forever????
>>I want a VFP-to-VFP "server" capability - something which I bet is DEAD **EASY** for them to do, but they won't. Why?? Well, it look like its to protect SQL Server sales. *IF* it is, then that's the lousiest reasoning in the world, and makes a DoJ Inquiry justified all by itself!
>>
>>End VENT
>>
>>Cheers,
>>Jim N
>
>Jim,
>
>I have to disagree with you on this. Or at least with your analysis. But before I state my specific disagreements, let me state that I agree with yon re: some rudimentary security in the DBC. Now, having said that...
>
>VFP never was touted as a server product. VFP, to my knowledge, has always been a great database language and local data store with network capabilities. It is not SQL server nor does it have SQL server's features. I would not expect it to have them.
>
>I agree that there are some features that MS should add to the product. But, VFP cannot be a panacea for all database apps. Nor would I want it to be. Personally, I have no problems moving to another backend when the situation requires it.
>
>Let me try this another way. IMHO, the concept of everything in one box doesn't really work anymore. Just like I want to develop classes and reuse them accross many applications, MS is touting the same strategy. Each tool in the MS suite has its strengths and weaknesses... we choose a tool based on what is best for the situation.
>
>As for the DOJ, I think the argument is spurious. Noone is forcing you to SQL Server. You could just as easily move to other SQL type back ends or, in fact, any ODBC compliant back end. I see the MS strategy as being simple. VFP is not a SQL back end with all that emplies. If you need that, go to another back end.
>
>Is this any different from PowerBuilder? Unless it has changed (and it may have, my knowledge is considerably outdated), doesn't powerbuilder use a "personal SQL" type product for its local data store?
>
>Personally, I would like to see some security features on the DBC. Perhaps a trigger that fires on database/table open. But, I understand the MS response.
>
>JOMO