>Bruce,
>
>I've been using my own framework since 1995 when we got the VFP 3.0 BETA so I've already designed a lot into the forms to handle the DE and multiple DBCs. However, I haven't worked yet with Remote Views and that's what I've been recoding everything for so I could change all of my forms to now support views verses table buffering. I wrote a couple of utilities to loop through all of my forms to change the ControlSources and such since I changed to Views.
>
>I feel like I'm in another paradigm shift going to Views the same way when we went from FPD to VFP!
>
>Thanks for the help.
>
>I'm curious about Stored Procedures though in having multiple DBC's. Do you have to set the active database to the one that has the SP before calling it. For example if your DBC on the server has the SP for adding a new record to the table for a PK and you are using a View in a local DBC. Do you have to select the DBC that has the Base Table first?
>

To call a stored procedure in a FOX DBC, it must be the active database. You can handle it like saving and restoring work areas, a la Fox 2.6:

lc_CurDBC = SET('DATABASE')
SET DATABASE TO <2nd dbc>

* call the stored procedure, etc.

*- reset the original dbc.
IF NOT EMPTY(lc_CurDBC)
SET DATABASE TO (lc_CurDBC)
ENDIF

If you plan to do this often, I recommend rolling this into a class, using the same principle as the Codebook "cSelect" class. This would simplify code to:
*- Save the current database and select the new one.
lo_DBC = CREATEOBJECT("cDBC", )

While a bit bizarre, I have handled the situation using Fox-pass-thru, meaning that all stored procedures exist in the local DBC. However, some of them may just switch databases and call the same proc in another DBC, or in a SQL database. The reason one might do things this way is to simplify your code.

For example, let's say you have a proc to generate primary keys called sp_NewKey(). You can place this in the DBC, so your forms, classes, etc. can call it. Inside it, though, you can do the work of getting a key any way you want, including SQL-pass-thru, or a proc in another DBC. This can help eliminate branching logic in your interface code:

IF ll_UsingSQL
SQLExec(1, "sp_NewKey('Client')", "cu_keys")
ELSE
sp_NewKey("Client")
ENDIF

It imparts a slight performance penalty (if any), but allows you to completely eliminate all the DBC switching. It's your call.

Yeh, I know it's a little wacky. But if a novel approach could save time and grief, it might be worth considering.

Hope this helps.

- Bruce Allen

>TIA

"Problems cannot be solved at the same level of awareness that created them." - Albert Einstein

Bruce Allen
NTX Data