Mike Yearwood
Toronto, Ontario, Canada
Information générale
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Versions des environnements
>>A "multi-user application" can have local exes and local dbcs. The DBFs need to be shared, not the DBC.
>
>While I totally agree on having local dbc's for views I don't think the dbc's describing normal tables ought to be *always* local. While "alter table" is not the typical command inside an app it might be dangerous to assume it never will be run. As long as you don't use "select *" in your view-definition you won't always have to recreate the local dbc's, but it might happen if you need the new fields. Here I am a solid believer of "it depends" <g>.
First off, Naomi is the one saying that a multi-user app MUST have a shared DBC. I'm saying that it may be local, not that it must always be.
Think over what is required to support having a local DBC. Never alter the main tables programmatically - sounds like a maintenance function. If the code programmatically alters tables, what's to say the screens will function? That's dangerous. Sending a new EXE when a DBC changes? Seems good to me.
What about the shared DBC? 100,000 loop to try to connect? Does that seem reasonable? Workarounds to break out the views just to avoid a potential deadlocks when several users try to run one query?
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement