Newsgroup: it.comp.appl.access
Titolo: Dove vengono memorizzate le informazioni sulle tabelle collegate?

Mi pare di vedere che le informazioni relative alle tabelle collegate 
siano mantenute su MSysObject
Vi risulta che siano SOLO la' oppure c'e' qualche altro angolino dove 
vengono memorizzate queste informazioni?
 
Chiedo questo perche' vorrei capire se sia possibile 'switchare' da una 
base dati ad un'altra semplicemente cancellando e copiando righe dentro 
questa tabella
 
Ad esempio, stessa procedura che attualmente e' collegata a db 
fisicamente su SqlServe/db1, ma che si desidera collegare a Db2/peppe2
 
Lanciando la procedura 'sgambio_db1_peppe2', sulla MSysObjects da codice 
vba si potrebbero eliminare le righe vecchie (solo quelle relative alle 
tabelle collegate)  ed inserire quelle nuove
O ancora meglio, modificando il contenuto del campo 'connect' dovrebbe 
essere pure piu' veloce
Stiamo parlando di due db con a stessa struttura
 
Il motivo per il quale sto chiedendo se sia possibile eseguire questa 
procedura sta nelle prestazioni, attualmente la mia procedura di 
collegamento tabelle porta via quasi un decimo di secondo a tabella e 
sto cercando modo di velocizzarla in modo sostanziale
Che dite, ravanando sulla MSysObject si riesce a switchare da un db 
all'altro?
 

 tabelle porta via quasi un decimo di secondo a tabella
 
ma quante tabelle ci sono? 36mila? inventati una bella barra di 
progressione che si colora man mano che le ricolleghi e l'utente almeno 
vede che sta succedendo qualcosa e non si preoccupa.
 
-- 
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........

 
 
Ce ne possono essere quante vuoi, non e' quello il punto
Il punto e' che se ci metti 1 secondo ogni 10 tabelle, e volessi 
switchare su un altro db con 500 tabelle, ci metti 50 secondi
Tu ritieni siano sopportabili 50 secondi (ad esempio) di attesa per 
l'operatore di quella postazione? Per me sono un po' troppi, ma pure 20 
secondi a mio avviso sono troppi, dopo qualche secondo, iniziano a 
pestare i tasti in qua' ed in la' alla ricerca della combinazione magica 
per interrompere il tutto, ovviamente con l'altra mano stanno gia' 
chiamando per segnalarti che c'e' qualcosa che non va
Comunque gia' ora la soluzione c'e' basta che usi due o piu' programmi 
ognuno collegato alle tabelle del suo db e sei a posto
Ma, per usare un francesismo, e' una merdata
 

 Ma, per usare un francesismo, e' una merdata
 
 
Spesso fai le domande ma già conosci le risposte: un metodo istantaneo per ricollegare le tabelle non esiste.
Quindi, o metti come ti suggerisce Ammammata una barra di progressione che aiuta gli utenti a passare il tempo, oppure crei più copie dei FE già collegate al rispettivo DB.
 
Saluti
 
P:S: Ma non cercare di convincermi che devi riconnettere 500 tabelle
 
 


Forse io lascerei i fe sempre connessi a tutti e due i database..
Così facendo cambi i recordsource e le querydef delle singole maschere/query via via che vengono aperte.

 Così facendo cambi i recordsource e le querydef delle singole maschere/query via via che vengono aperte.
 
A volte lascio sia i miei link che p.e. i link al server SQL del cliente 
nel frontend. All'avvio, a seconda dell'ambiente corrente, le tabelle 
collegate vengono scambiate=rinominate, cioè vengono aggiunti e rimossi 
prefissi come "dev_" o "real_". Questo richiede solo una frazione di 
secondo.
 
-- 
Ciao
Karl
*********
Access News: 
https://youtu.be/XMOHBSudo-U
 
Access DevCon: 
http://AccessDevCon.com
 
Access FAQ: 
https://www.donkarl.com/it
 


Non ho capito bene
Dici che se il db ha 10 tabelle, e sono tre db diversi, potrei fare un 
collegamento iniziale a tutti e tre, e quindi il programma 'vedrebbe' 
sempre trenta tabelle ma ne dovrebbe usare solo 10 alla volta?
 

 
 
Stiamo parlando di accedere via odbc?
Cioe' su tuo sistema sviluppo i dati sono su Server1\db1 mentre su 
sistema cliente sono su Sql2\dbcliente
E non e' necessario il ricollegamento di tutte le tabelle?


No in effetti non sono 500, era solo un esempio
In realta' sono di piu'


si questa era la mia proposta..

 In realta' sono di piu'
 
Addirittura!
E cosa sarebbe questa gestione, un clone di SAP?
 
Saluti


Hai idea di quante ne abbia Sap?
Credo che neanche molti consulenti lo sap-piano
Perdonate, ma non ho resistito
Comunque stiamo parlando di un ordine di grandezza delle centinaia di 
migliaia, credo 'diverse' centinaia di migliaia
Un gestionale che conosco personalmente, TargetCross quello della 
FourSolution di Modena, nella versione base c'ha almeno un migliaio di 
tabelle
 

 tabelle
 
Vabbè, ma sarei curioso di sapere cos'hai fatto tu, per gestire centinaia e centinaia e centinaia di tabelle.
 
Saluti


Se devi fare qualche bolla e fattura quante te ne servono a te? A me 100
E per la contabilita'? Altri 100
E per il crm? 100 in piu'
Per le serre? pure altri 100
Per la tracciabilita'? Altri 100
Visto che ci siamo arrivati !!!

 migliaia, credo 'diverse' centinaia di migliaia
 
quello che ho qui sul server, SAP Business One, detto anche SAP-pino, 
ne ha poco meno di 3000 (incluse quelle dei log e quelle utente)


 
 
Ecco, per la delizia del Simone, or lo sappiamo con teutonica precisione 
   (per chi non lo notasse, c'e' la rima)
Ed il SapHana quante cenne avvra' ?
 

 ne ha poco meno di 3000 (incluse quelle dei log e quelle utente)
 
 
La versione Standard dovrebbe averne (almeno qualche anno fa) circa 8.000
Certo, non proprio centinaia di migliaia...
 
Saluti


Qua sembrano un pelino deppiu'
https://www.tcodesearch.com/sap-tables
 

 
https://www.tcodesearch.com/sap-tables
 
 
Mah, mi baso su quello che ho visto da un cliente di cui curiamo la parte amministrativa.
 
Saluti