Jim, I'd like to re-comment on a few of your lines :
>Hi Peter, > >>Why this would be needed ? >> >>
Old code >>>....
>As regards "one should use the latest techniques", again I don't really think so. Nothing wrong with the idea at all, but I just don't think that the whole VFP world is doing so. Many guru say that remote views are crap. I can't find information on performance expectations when deploying Web Services. SQL Server offers much more powerful SQL than does VFP. Now sure, people use these and many more "latest techniques", but I bet that far more do not. Many of the "latest techniques" have their use in that niche called the Fortune 500, but the small/medium business world, comprising a HUGE market where FP (yes) and VFP is used, have much simpler and straightforward requirements. Old code and old logic works very nicely in those areas and will do so for a long time to come.
IMO these persons (or instances) can be divided into two categories : 1. The ones just having old code (happy with it or maybe not but nothing to do) 2. The ones (BTW like me) with an opinion that using the new techniques may go too far, and is no objective by itself. They wait for the technique being prooved and don't go web-enabled because the neighbour does, and don't use COM because COM+ may come around soon. Yea, and because of that they don't understand about ADO anymore. Oops.
In the end I agree with you Jim, as long as these same persons see the light on having to step to certain "techniques" like DB-independency. This mixture makes life hard for these persons, and (in this case) MS should be able to help them. Also note that there are more or few apps around from the beginning of FoxBase where these techniques just weren't available, and in the mean time the app grows and grows, making life harder and harder once the step HAS to be taken. Own fault ? I don't know ...
> >> >>
2GB Limit >>Maybe I am surprised that this one is treated more or less as a sub-topic, where this is the most serious thread to us all. Well, if we really like to be ‘big’ or ‘more real’...
>In my comments about this I said that I would NOT include it in my wish submission. It's not that I don't think this is an important problem, but rather that it "interferes" with the central theme of the wish. >But I would suggest, just to be difficult, that this needn't be "too hard" within a 'server'-type component. Since a 'server' would/could manage such locks all within itself then various techniques could be employed to achieve the goal. Doesn't answer for a "regular" VFP deployment though.
I know you said that Jim. Two things : 1. Once the real topic is addressed to by MS it would be stupid not to solve this one at the same time; 2. I don't think 1 can be achieved by having xBase tables withing the Database-server principle. I mean, it won't change the problem (for MS), I think.
And that is exactly why the approach should be more general (read : just have a SQL-based solution), because THEN the problem will be desappeared by itself and there is just nothing to solve. Okay, unless we wish for xBase tables explicitly at the DB-server. Now let's turn things around :
I take myself as an example, having commercial problems with Fortune 500 possible customers. They KNOW they have to pay for licences, and have the budget for it in advance. Now MS starts to deal with this wishlist topic, KNOWING that if your wish will be met litterally (xBase tables, noting more for now), Fortune 500 companies won't buy SQL-server for sure. So what should MS do ? all BUT allowing for xBase tables.
What about that huh ? And okay, of course it is not allowed to respond to this like "yea, but now my selling would be more expensive and hence I'll sell less ...". Agreed ?
> >You've given this a lot of thought, Peter, going far deeper into showing that there are ways to accomplish the wish than I did. This is important, I think, in convincing other developers of the viability of the wish. But I do not intend to include these in the wish document, prefering to let the VFP Team come up with the best and most practical design given VFP's existing structure. >You've also given more detail about the real need/value for such a facility as well as the benefits of it. > >I really appreciate that. It helps a LOT! > >I have no problem at all with someone else proposing a similar capability for SQL Server or Oracle or whatever. I limit it to VFP specifically to keep the wish small(?), clear and focused and because I believe that there would be a very big market for a VFP-only feature of this kind. >
I am not sure (and not sure what you say); It looks like you're saying that the proposed possibilities (by Bob Lee too) should not be handed to MS in order to have them objective and find the best solution ? If that is what you are saying, I don't know whether that is the best idea. Suppose, just suppose they don't come up with these ideas taking (possibly) far less time than any normal way of thinking, the task may be too large to begin with, or, just costs to much without real revenues. IMO it can't harm to feed them with a few brief lines on f.e. changing the "compiler" from native xBase commands to SQL commands (higher level commands where possible). Just to indicate the direction. I think we all know this thing is more heavy and of more general interest than a wish for another kind of treeview or whatever; this allows for -IMO- some more lines. With focus of course.
