>Hello Peter, reading this thread, and following it, I feel I too must comment on a few of your subjects..
>
>>
>>Yesterday I found this thread, which started at 20-09,
>
below is a response to all of it.
>>
>>Why this would be needed ?
>- My Updated Response.
>I have been thinking about this issue for a few days, and maybe came up with a slightly different response.
>
>Maybe Microsoft does not need to create yet another Server Database. But, VFP is a fine tool as a front end tool to work with any Backend server.
>So be it.
>If VFP connection tools to odbc or ole-db or whatever someone wanted to use to connect to 'other' datsources in VFP were improved. the VFP product could be thought of and used as a true FRONT end tool of choice for database developers.
>
>as an example. what if you wanted to create tables on a server, Sure you could do this in code, but why not graphically. ? right inside VFP.
>
>a command could be build like
>
>set database to mydatabase remote && Mydatabase could be pointed somehow
>to an odbc database. using DSN ..
>
>then what about use mytable alias mylocaltable && which resides on thes server.
>a backend command could create the necessary command, to do something like
>select * from mytable limit 0,0
>and then send the command behind the scenes to the server.
>what you now have is an empty read write cursor.
>
>you then issue browse
>and the same command, fetches 50 or 100 records.
>sounds like remote views. but I ask why have to bother with remote views. ?
>
>cant VFP be programed to create the concept of remote views on the fly, without having to program them.. ???
>
>sqlexec can get a list of tables on the fly, can get field names from a odbc database.. ? why cant is just create the cursors necessary on the fly. no need for the vfp coder to create these things called remote views.? Isn't that what the server is for anyway. Stored proceedures. ?
>
>I can use a server 'view' from a remote server, and the backend process what joins I need.... Why does VFP have to duplicate that functionality on local tables and cursors. I ask why not just add those type of features to VFP data engine... and let it fly.
>
>Sure building remote tables, (sql tables) have rules which DBF dont require. Like adding PK to a table is a requirment ...
>
>But the more I think about this. VFP could be BOLTED onto an ODBC datasource, and then let the data fly... Form fields connected to VFP cursors built on the fly, with something as simple as
>
>set datasession to remote [dsn]
>
>Why not ?
>
>Bob Lee
Bob,
I really like your approach here, looking as creative as I myself usually look at things.
I have a few general remarks on your lines, or want to put them in another perspective.
First of all, please note that I am NOT the SQL-experienced and that I -up till now- work from theories only.
Secondly, the number of possible solutions ir rather infinite, thinking of all the combinations which can be made. This is exactly the reason why I DID start this project half a year ago, but DID NOT come to a definite solution yet.
Back then, I started with the definition of "cursor" which just cannot be derived from the Fox docu, but which is IMO crucial; With this phenomenon in mind, I have my next remarks. Please shoot at them, when I'm not right on a topic :
DBC
Although I foresee that a DBC is helpful, I (read : out app) cannot use a DBC in full extention for the next reasons :
A guessed factor of 4 more indexes will come out of that, because of the logic of the database-designer doesn't give the possibilities which are intrinsicly in native tables (logical subsets thinking of left-most keys being equal, representing f.e. a company).
I realize that this may not apply once a remote SQL-DBMS is in order.
The number of entities used in our app (over 1,000) far exceeds the allowed number in the DBC. That is, if this has not changed in VFP7.
Further, the graphical support won't allow it being useable (I saw a thread on this yesterday).
Remote Views
This is the most logic part of it all, allowing for transparency with respect to the manipulation of native tables.
However, a Remote View will imply a physical copy of data to the desktop (or other place on the server if you like), implying a huge amount of unnessecary I/O.
It is my remark that I do not know whether this can be set up that dynamically that this problem may be overcome (let the View read 20 records at a time or so). And :
I expect problems in the transaction - or locking area;
After reading all there is on this, there seems no way that really matches 1 to 1 the logic of the useage of native tables only. However, I feel that this can be solved at the higher level.
Transactions
Referring to the last topic above, now unaccording to Remote Views, in general counts that the logic around locking cannot remain the same.
Where a Transaction can be defined as an implicit phenomenon with native tables, with remote tables this cannot be achieved. I'm talking here about the Lock on a record in various tables implying the beginning of a "transaction" on that table, and once this is performed on more tables, they are all incorporated in the Transaction. An Unlock All at the end of the Transaction, applies all at once to the database.
I do not say that Transactions cannot be achieved on remote tables, but I do say this cannot be achieved in this implicit way.
With my knowledge (sorry), it all will come to possible rejects once a Transaction is committed. This logic can be overcome by users of any system (ours too), but it DOES imply different logic in the app as a whole, of which I'm not sure whether this can be dealt with.
Please note that this problem is actual for those apps not using Begin Transaction (etc.) from the beginning, which BTW is possible for over 10 years with some additional libraries. Since we are from 1986, at THAT time this just was not possible, en believe me, there will be more of these apps. Don't understand me wrongly with respect to our way of having logical transactions, which just are 100 % waterproof (in fact 99.9, but let that be another subject).
So Bob, yes I think your ideas are good, but having in mind the objective "let the old coded app run with remote DBMS" needs IMO the attention of my lines above. Fact is, that once we all (MS included) start thinking in ways I and you do, this will not be a multi-year project; In these days it all comes to the combining of existing facilities, of which there are more than we can think of. Whay is MS capable of letting VFP evolute as fast as it does ? IMO because of the use of existing components of f.e. VB and C++. I am sure if MS starts thinking in this kind of direction, they come up with even better ideas than we can all together. Well, that's what I hope for.
