Peter,
SNIP
>>
>>>
>>>
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.
I'm going on repeated statements by Craig B. quoting VFP Team members that this problem is deeply buried throughout VFP internals. And I think that we can generally get along OK with a 2gig limit for each table.
It is my feeling that SQL Server, from a data-storage point of view, is very similar to our "ISAM" data-storage and they solved it there. BUT they had the benefit of starting out with that objective (very large tables) whereas FP/VFP began when 2gigs was never even contemplated.
>
>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.
Well 'my' wish does include xBase tables (and only xBase tables) and I intend to keep it that way. It includes xBase and (VFP) SQL I/O commands.
I take your "SQL-based solution" to mean SQL Server based. Assuming that this is correct then I leave that for others to submit as a wish. (still didn't see one as of last night).
>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.
Nah, it won't happen like that. Look, there are no doubt many even smaller businesses where they do buy SQL Server just because they like to have the "latest and greatest" and because they fall for all the hype in its advertising. Or they fell for the rumour of VFP being a 'dead product'. But had this happened at a fast enough rate then I bet that MS would truly have shelfed VFP by now.
But more importantly MS retains 2 products to help to maintain shop loyalty to Win OS, even with the possibility (maybe small now, but who can see the future) of developing a Linux version for VFP (and SQL Server?).
MS' marketing likely knows the size of the markets involved and there is plenty of room for both for years to come.
>
>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 ?
>
SNIP
>>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 ?
Well keep in mind that VFP Team members have probably read what you and Bob have written. And if they haven't then they have to opportunity any time in the future because I made a direct reference to this thread in the wish content.
My "problem" with 'telling' them ways to solve the problem is that it is done totally in the context of the unknown. It is based solely on how each of us imagines the VFP internals are constructed. We simply don't know. But I guess that it is constructed far differently than any of us surmise.
Also, remembering that there was once going to be a server version of FP, I am confident that they have their own good ideas as to how to achieve it. Hell, there may even be code in there already toward the objective.
>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 agree that it can't harm. My only point is that I do not want to put these ideas into the actual wish document. The single example that I did include in the document was deliberately very general in nature, to give the VFP Team maximum flexibility in their design and also to give minimum possibility of rejection because some specific thing is 'impossible'.
But I think that, if nothing else, it would make for very interesting material to discuss this heavily right here in this thread.
>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.
So let's discuss various ways of solving the problem in this thread!
I'll start with yours - to turn all commands against remote tables into SQL commands for the 'server'.
I think this is oversimplified. More importantly, I think that this eliminates the probable advantage of being able to use much of the existing VFP I/O internals right inside the 'server' component. To me this is a key to making this job much smaller than it appears. As I said earlier, it may even be so that much of the required code is already there. And I doubt that it would be in the form of SQL commands. But if it is, then so be it. I guess we would never know, though < s >.
In another message of this thread you elaborated on xBase constructs that can slow things down dramatically if a SQL translation is used. I agree, but say that this need not be so using other possibilities. And the construct you use is a very common one. Remember, the objective is to have all old code work just fine, still with very good performance. If rewriting becomes required for different pieces of code then the advantage is seriously diminished.
I'll agree that your solution would make it much easier for the VFP Team to then adapt the same for a SQL Server interface and/or an Oracle interface, etc.
But that is not what *I* am after.
Jim
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only
