Newsgroup: it.comp.appl.access
Titolo: Come spostarsi rapidamente da un db ad un altro?

E' abbastanza comune, almeno nella mia esperienza, la necessita' di far 
collegare uno stesso front-end con db diversi
Il caso piu' evidente e' il classico programma gestionale, con archivi 
di aziende diverse
Quindi supponiamo un applicativo scritto con Access, che usa tabelle di 
un db server qualsiasi, collegate via odbc
Se desidero cambiare ditta, usando lo stesso programma (lo stesso file 
mde intendo), devo per forza attendere OGNI VOLTA il ricollegamento 
delle tabelle alla nuova base dati
E se le tabelle sono centinaia AND la necessita' di switchare ditta e' 
frequente, allora le lamentele crescono
La domanda e': come fare, usando uno stesso applicativo in formato mde, 
per spostarsi rapdamente da un'archivio all'altro?
E' ipotizzabile un file intermedio, un mde o mdb, messo tra applicativo 
principale e dati, che funga da 'memoria' tabelle collegate?
Oppure, come velocizzare le operazioni di ricollegamento tabelle?
Ciao e grazie
RobertoA
 
 


idee: 
 
multiazienza (aggiungi un IdAzienza ad ogni tabella e gestisci gli accessi). Vantaggi: sempre tutto sotto mano, non query eterogenee, semplicità di gestione. Svantaggi: nessuno 
 
colleghi tutto sempre: gestisci gli accessi (come prima) ma perdi ogni vantaggio ulteriore
 
Non si usa più fare db anno per anno. Ti giochi statistiche ecc ecc. Con le possibilità di oggi io manterrei la vecchia struttura


Ringrazio per la risposta
Il multiazienda, inteso come un unico db con record distinti per azienda 
in base ad un indicatore, non e' proprio vero che non abbia nessuno 
svantaggio, la dimensione del db stesso, oltre che le possibili 
commistioni di dati se non ben filtrati
Se hai 20 aziende (ad esempio un commercialista) la tua base dati, unca, 
si ingrandisce inutilmente

 si ingrandisce inutilmente
 
Soluzione piu' complessa: Just in time
 
Colleghi/ricolleghi solo quando ti serve
Generalente quel tipo di applicazione dovrebbe avere una serie di
tabelle /parametro/ che sono o dovrebbero essere comuni.
Queste possono restare sempre collegate.
Le altre sono specifice ma, in una applicazione, ci sono, in genere,
poche (oserei dire mai) funzioni che le richiedono /tutte/
contemporanemente.
Avevo da qualche parte una roba del genere ma fra pc scassati
e mio disordine ed il fatto che non /programmo/ piu' da una vita
e' rimasto solo un vago ricordo.
 
-- 
ac (x=y-1)
Aborro il Killfile
(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)


Tu hai parlato di un db server come di deve (non access/jet/ace), e quindi, a meno che tu non sia 20 Amazon, non credo che le dimensioni siano un problema. Se pensi a milioni di righe, per SQL server non sono un problema (ma neanche per MySQL, Postgresql....a volte neanche per un mdb). Se i dati non sono filtrati bene, il problema lo hai anche su basi separate, se il programma è fatto male è fatto male! Ma se ti serve tirare una query tra n basi come fai? Colleghi e ricolleghi? E se non sei in locale? Chi la fa la query? che motore? Cominci a tirare join tra db eterogenei....auguri! E se aggiorni una base dati, aggiungi un campo? Lo fai per tutte le basi dati? E se devi propagare delle modifiche? Per me è un suicidio...Ci sono una ilionata di "E se". Tu mi parli di collegare un FE a tanti BE, quindi sono tutti programmi uguali, si occupano della stessa cosa. Ergo, la gestione multiditta è il sistema più indolore (a parte aggiornare query e procedure, ma quello lo fai una volta e stop), perchè lo fai e nn ci pensi più. Quando entri ti logghi e gestisci gli Id. Concettualmente è semplice (magari farlo è un bagno di sangue eh?!?!). Ci sono a limite tante strade intermedie, ma il problema non lo risolvi completamente.....IMHO

 per spostarsi rapdamente da un'archivio all'altro?
 
 
Devi decidere tra le 3 strade che conosci:
 
1 - Db unico multiaziendale
 
2 - Connessione a Base Dati con centinaia di tabelle
 
3 - Sbinare i Front-Ends (ognuno collegato a un Database): soluzione che 
adotto in casi come il tuo, senza problemi.
 
Saluti 
 
 


Si certo come prestazioni, da 1 milione a 20 milioni di righe non cambia 
granche'
La mia volonta' di mantenere separati i db delle varie aziende era 
dettata piu' che altro dal fatto che dispongo gia' di diverse procedure 
che funzionano in questo modo e quindi volevo trovare una soluzione 
'solo' al ricollegamento tabelle, oltre al fatto che mi sono 
intestardito a fare cosi'


Eh si, il fatto e' che vorrei arrivare a conossiere strade nuove
 

 e' rimasto solo un vago ricordo.
 
Si anche questa e' una possibilita' che sto valutando
Il 'ricollegamento dinamico' alle singole tabelle usate nella form avviata
Ed analizzando la cosa nei dattegli credo potrebbe essere di notevole 
efficacia
Avrei pensato di mettere dentro un file ini nelle stessa directory del 
programma, una riga del tipo Ricollega_Tabelle=12345678, dove il numero 
indicato sia univoco un guid o roba del genere
Ogni form avviata, prima di accedere ai dati, dovrebbe controllare che 
le tabelle usate abbiano tutte (nel file ini) il valore 12345678, una 
roba del tipo Codici_Iva=12345678
Se cosi' non fosse, vuol dire che la Codici_Iva deve essere ricollegata
Ovviamente dopo il ridollegamento verra' aggiornato il numeretto nel 
file ini, in corrispondenza alla tabella ricollegata
Nel caso di cambio db, le singole schermate ricollegheranno le tabelle 
usate, perdendo qualche secondo ma solo la prima volta che verranno avviate
Finora e' questa l'ipotesi in pole-position


Io la avevo fatta piu' semplice (probabilmente sbagliando)
Il mio DBEngine /sa/ quali sono le tabelle collegate io dovrei sapere
quali sono le tabelle che mi occorrono.
Perche' scomodare il file di configurazione forse e' sufficiente una
tabella /dizionario/ tabelle che oltretutto access da qualche parte la 
deve anche avere.
Dal mio menu' (forse e' questo il collegamento che manca) io dovrei
sapere quali sono le tabelle che mi sono necessarie per quella
specifica funzione il resto e' semplicemente un /veloce/ controllo
sul CurrentDatabase



Si certo
Ma non le ricollegherai 'ogni volta' che le usi?
Ci dovra' pure essere un sistema che ti permetta di ricollegarle solo se 
cambi front-end, la prima volta che accedi a quella tabella
E' questo lo scopo del sistema sopra descritto, capire se e' la prima 
volta oppure no
 


 
Ma non sta scritto gia' nella collezione Tabledefs se e' collegata e 
dove? E la Tabledefs non e' accedibile per indice /associativo/ ?
Normalmente  un DB relazionale le informazioni che  riguardano la
struttura  le ha /sempre/ conservate da qualche parte.
Il tuo .ini mi sembra semplicemente un di piu'.



Nella Tabledefs ci sara' sempre qualcosa, a meno che uno non vada a 
cancellare le informazioni
Il problema e' che nella Tabledefs potrebbe esserci l'indicazione di una 
tabella che nel sistema attuale non c'e'
Esempio, io sviluppo e faccio l'mde con db in C:\DB\PIPPO.MDB
Poi passo l'mde al cliente che avra' il db in D:\LAVORO\DB\PIPPO.MDB
Dentro la Tabledefs l'informazione ci sara', solo che sara' il percorso 
vecchio, sul mio sistema e non quello attuale dove trovare i dati
 


In passato, io ho operato così: un mdb Locale con dentro le mie tabelle di configurazione. In questo caso LinkedTables, con nome tabella ed eventuale percorso, anche misto tra SQL server, tabelle locali e via cosi. Ho un file con le eventuali informazioni di connessione e routine all'avvio per la connessione di default. Se devo cambiare base dati, ho routine che leggono la nuova connessione (o ti aiutano a scriverla), la tabella suddetta, e ciclano per il relink. Per la lentezza che dichiarate, questi sono i miei dati: 102 tabelle su SQL server, 46 tabelle su mdb. Tempo di switch tra le basi dati: 20/25 secondi, in multiutenza e senza macchine bestiali, anzi, un pc ha ancora XP e 516 mb di memoria. Io non mi lamenterei e non smetterei di cercare soluzioni esotiche

  Io non mi lamenterei e non smetterei di cercare soluzioni esotiche
 
 
Neanche se fanno la hula?
Probabilmente era /smetterei di cercare/  ;-)


Già.....