Script per ricollegare le tabelle
Pisinho
tempo fa chiesi come era possibile ricollegare tramite VBA le tabelle in
modo da poter gestire l'ambiente di produzione o di test.
Facendo delle ricerche anche su Internet ho notato che si usa sempre DAO per
fare queste cose, ora la mia domanda è:
Come mai si usa DAO per ricollegare le tabelle mentre dopo posso usare ADO,
è solo perchè DAO ha delle funzioni che non ci sono i ADO, per semplicità o
cosa?
Viceversa, non esiste altra maniera per modificare il collegamento ad un
altro databases ? (TEST, PRODUZIONE)
Grazie e scusate se ripongo una domanda già fatta in passato.
Pisinho
>
> Viceversa, non esiste altra maniera per modificare il collegamento ad un
> altro databases ? (TEST, PRODUZIONE)
>
> Grazie e scusate se ripongo una domanda già fatta in passato.
>
>
Nel frattempo spippolando un pò ho visto che nella tabella MSysObects c'è la
stringa di connessione al Server, quindi potrei leggermi la tabella,
modificare il campo con il NUOVO SERVER, e ricollegare le tabelle.
Avendo Da modificare SOLO tabelle collegate ad un server SQL Server, va bene
lo script che c'è sul sito comune oppure ne avete un altro da suggerirmi ?
Saluti
@Alex
Ciclati la Collection Tabledefs e stampa nella finestra Immediata la
proprietà CONNECT delle Tabelle...
Leggi che salta fuori, sappi che tale proprietà è READ/WRITE... ;-)
Ciao
@Alex
SuperKetto
Ciao c'e un tool già fatto su www.mirkopetraroli.com
Bruno Campanini
news:4c724043$1...@news.x-privat.org...
Se ho capito bene: da un Client devi collegare il FE una volta
a un set di tabelle (residenti su un Server) che si riferiscono
al database TEST, un'altra volta al database PRODUZIONE.
Userei questa procedura:
1 - una tabella sul FE contenente i due set di tabelle, con
flag che contraddistingue l'appartenenza a TEST ovvero
a PRODUZIONE
2 - un po' di codice VBA che a seguito di un valore in input
(flag) scollega tutte le tabelle collegate e collega quelle
relative al flag.
È questo che chiedi?
Circa i quesiti su DAO/ADO, per me si tratta più di una scelta
che di altro (almeno tutte le volte che esiste l'alternativa).
ADO appare comunque abbastanza obsoleto rispetto al
DAO, anche se questo è più vecchio di quello...
Bruno
Pisinho
>
> È questo che chiedi?
> Circa i quesiti su DAO/ADO, per me si tratta più di una scelta
> che di altro (almeno tutte le volte che esiste l'alternativa).
> ADO appare comunque abbastanza obsoleto rispetto al
> DAO, anche se questo è più vecchio di quello...
>
> Bruno
Si Bruno è quello che voglio fare, diciamo che con lo spunto di Alex e
cercando in rete sono già riuscito a fare quello che chiedevo ma un'altra
soluzione è la tua,
l'unica differenza è che se modifico una tabella devo ricordarmi di
aggiornare anche la tabella delle definizioni il chè è lavoro in più,
comunque è valida.
Per l'uso di ADO e DAO fin dall'inizio di quando ho cominciato chiesi un pò
in giro quale fosse il metodo migliore o almeno quello che sembrava essere
il modello che proseguiva,
mi dissero che era ADO.
A questo punto mi metti in difficoltà e chiedo se così fosse è meglio
iniziare a capire DAO ?
O meglio come qualcuno aveva postato ci saranno nuovi sviluppi a breve e
forse ci sono già con ACCESS 2010 ?
Comunque grazie Bruno.
@Alex
Con Access, a meno di lavorare con progetti ADP è assurdo usare ADO
che lo obbliga ad effettuare conversioni implicite in DAO.
In generale però, considerazione non valida per Access, ci sono in
merito moltissimi 3D che dicono l'uno il contrario dell'altro... è un
pò come
definire se sia nato prima l'uovo o la gallina...
Gli ORACLISTI tuttavia hanno sempre perpetuato DAO inconnessione
ODBC... è sempre stata MS a portare avanti ADO, abbandonato di fatto
già da tempo a favore di ADO.NET nemmeno lontano parente di ADO di cui
ha solo un nome simile e nemmeno lontanamente accessibile da Access
per ora...
@Alex
OneEDP
http://groups.google.it/group/it.comp.appl.access/browse_thread/thread/e78546b3bcb999de/763b5588367a949e?hl=it&lnk=gst&q=segnalazione+link+di+interesse#763b5588367a949e
Ciao
--
Daniele
Rispondere scartando OneEDP, spam e 32
OneEDP
Bruno Campanini
news:bf1a61c3-f0b0-45d9...@m1g2000yqo.googlegroups.com...
> Con Access, a meno di lavorare con progetti ADP è assurdo usare ADO
> che lo obbliga ad effettuare conversioni implicite in DAO.
> In generale però, considerazione non valida per Access, ci sono in
> merito moltissimi 3D che dicono l'uno il contrario dell'altro... è un
> pò come
> definire se sia nato prima l'uovo o la gallina...
> Gli ORACLISTI tuttavia hanno sempre perpetuato DAO inconnessione
> ODBC... è sempre stata MS a portare avanti ADO, abbandonato di fatto
> già da tempo a favore di ADO.NET nemmeno lontano parente di ADO di cui
> ha solo un nome simile e nemmeno lontanamente accessibile da Access
> per ora...
>
> @Alex
Fra l'altro...
Access 2010 (64bit) non accetta più fra le References il
DAO 3.60 che ancora appare listato (error in loading DLL).
Però si creano e funzionano i vari DAO.Database, DAO.Recordset,
DAO.TableDef, etc.
Il che significa che il DAO (o qualcosa che gli equivale) già
ce l'ha nella pancia.
Mentre è ancora possibile caricare ADO 6.0, del quale non ho
verificato il funzionamento.
Bruno