>I recently purchased the book Special Edition Using VFP6 and there is a topic about using Bound vs unbound data. Similar to VB where you can use a data control to bind the data to a table I understand I can bind a text box on a form to do the same thing, As a textbox is is tyoed in the data in the correpsonding field is updated or added. But what if you need to do some conditonal processing before adding the new record? Can you use SQL to add the record? Wont I have more control of the data If I dont have the textbox tied directly to a field? I know the preferred way is to use the control source but I would like to to try adding it a different way.
>
>
>Basic Data Entry screen
>
>Last Name
>First Name
>Address
>
>once info is entered how do I add it to a single table or multiple table in a multi-user environment?


Anthony, maybe you won't find many co-thinkers on unbound data, but IMO this approach is right. Working unbound, you'll have just another layer completely disconnected from all, except from the GUI itself. I know, (see other Message) that this is sort of achieved too by means of binding to a cursor, and the cursor acting as the communicator between your forms and the database (which may be any then), but IMHO this still aint right; it is exactly as you say :

once you have to do some manipulation on the form's control, things start to become more difficult than helpful.

Just look at it from the other point of view : suppose you work unbound from the beginning, you'd allow yourself to do all what you needed; not only from the form to the DB, but also from DB to form. Right ? It may be about Transforms, showing things upside down or whatever, and you'd need "calculated fields" in order to cope with that;
when our app was ported from FPDos to VFP (and FPDos was unbound), the very first thing I did, was having some "calculated field" function, which I managed to get running, even on the cells of grids. It wasn't that fast, but it worked. However, it was too difficult too, and it needed exceptions all over the place, and in the end I quit that path. It was just doing difficult. Right now our app works like this :

Each function (= 1:1 with form) assigns euqally named variables to each (needed) field from the DB at initialize. This is done outside the form, hence this is a business function. The variables are twisted like the app (originally) wants, i.e. as upside down as the app needs.
Now each of these variables imply a control on the form, and f.e. whether a Y/N or a .T./.F is in the DB, a checkbox will be on the form. You see ? another useful disconnection from the DB; Each of these variables is the ControlSource of the according control, and there is no property needed for this. Hence, this is not a solution which needs bunches of properties on the form (or other biz-object) in order to have the variables somewhere; they are just private to the function, and the function initiates the form so the variables are scoped to the form. Now note that the variables remain unique as long as the naming of your DB fields is 100 % (normalized etc.).

Any change of the contents of any control, will automatically get into the according variables, because they are the ControlSource.
Well, when the form is finished, the function twists again with the variables as needed for the representation in the DB.

Please note that this sounds simple, but that there's much more to it, when you really want to disconnect the means of GUI from the business functions; this is about the Valids. And no, the solution is not in Stored Procedures, because they are DB-dependent. So another "layer" is needed, which is similar to the above described, but now for Valids i.e. validations at control level. It is similar, because again the ControlSource implies that the variables are available to the app, which is btw nothing different from having the DB-fields as the ControlSource. Like the solution with a cursor, this is a means to validate unaccording the back-end DB, though I don't agree 100 % with this solution. Again look at the Checkbox, and its value .T. and .F.; when the DB back-end DB contains Y and N, what will the cursor contain ? if it's Y and N there must be some transformation from the Checkbox to the cursor's field. Right ? when the cursor contains Y/N there must be a transformation from the cursor to the back-end, right ?
So what this comes to, is the twisting of the value in code again; well, this therefor doesn't need the cursor at all. We have the Y/N in the DB, because "space" is another value for Checkbox. IOW, "unassigned" is (for us) a legal value for Checkox, and hey, the Checkbox can contain three values. That it can't show it is something else, solved (by us) by another colour of the Caption.

Anyhow, when you want all 100 % disconnected, the control's Valids should interact with the function again. So, the function contains the Valid code per (needed) control, and this code must be ready to be called from outside the function.
Now watch it, because with the Checkbox as the example, there is this other layer needed, in order to change the Value from the Checkbox to the original value from the variable. In our case this is from the Value of the Checkbox to the according "Y", "N" and " ". This has to be done in the Class somewhere, which is allowed because the Class will anticipate on the bizmodel (the bizfunctions). This is not allowed to be in the functions themselves, because it would make hem dependent on the GUI level again.

The logic of the remainder is easy; in the Classes there will be general methods changing the "Y" into 1 at some GotFocus, and back to "Y" at some LostFocus (it can't work like this at all, but it's to get the idea). What this in fact needs, is another layer of "ControlSources" because the Checkbox Value just can't have a "Y", "N" or " ";
Now though this looks difficult, it is rather easy, once you start thinking of proper naming again, and you can just add another set of variables for those controls who need that (like Checkbox). This other set of variables become the ControlSource, and the general methods assign those variables to the function's variables with the according value.
Note that the InteractiveChange is highly benefecial for that, were it not that in VFP5 this just doesn't work properly. So you'd have to do that yourself with some extra code at class level. But no problem.

Note that the above wasn't about DB-independency within the biz-functions themselves, and if a SEEK in there, you would be doing native VFP. So yes, that can be solved with cursors which is IM(H)O the best way. But this has few to do with the above.

Anthony, few people will agree with this, because it just isn't done. For me it is THE way of working, and when we create our bizfunctions we don't know at all what GUY is behind it. There isn't even one property-assignment in the biz-functions, which about nobody will understand. It is done by the above of which I btw hope it is more or less clear ...