Newsgroup: it.comp.appl.access
Titolo: Le stranezze di access, caso 1: tabella allegata corrotta nel FE dopo modifica BE

Access 2003, Windows XP
ho un applicativo con FE e BE, BE messo su un server di rete aziendale e i 
FE su alcuni client
Dovevo fare delle modifiche alla struttura dati del BE, compreso un 
intervento sulle relazioni.
Lavoro che avevo testato su una release del FE e tutto ok.
Blocco i lavoranti sui FE e faccio le modifiche.
Rimetto sotto il BE e gli dico di ripartire
Mi segnalano un malfunzionamento su una casella di riepilogo che non da 
dati.
Ok, controllo, ma le modifiche sulla struttura dati non avevano impattato 
sulla tabella di quella casella e mi pareva strana la cosa.
A quel punto entro "da dietro" nel FE, apro la tabella incriminata e mi 
trovo un fottio di #errore, ma non su tutti i record. E mi dice che magari 
la tabella era danneggiata.
Strano.
Apro direttamente il BE e la tabella è perfettissima.
????
A quel punto prendo la nuova release del FE, la distribuisco e tutto 
rifunziona regolarmente
E' come se il vecchio FE risentisse di qualche settaggio della struttura 
dati precedente e quando si è collegato al nuovo BE sia andato in palla.
Ma è assurdo!!!!
Antonio
P.S.
Seguirà altra anomalia, pure peggio...

 Seguir altra anomalia, pure peggio...
Ma nel FE effettui il Relink delle tabelle semplicemente oppure non lo
effettui...?
In entrambi i casi il FE ha memorizzato la struttura, ed il semplice
RELINK non la aggiorna, mentre se non effettui nemmeno il RELINK è
altrettanto ovvio.
L'unico modo per evitarlo è costringere il FE a rileggere anche la
struttura della tabella, cosa che non fa con il semplice RELINK basato
sul rinfresco della Connection.
Per forzare la rilettura devi Cancellare le Linked e ricostruirle.
In particolare questa anomalia con un SERVER SQL è molto evidente, per
questo io alla chiusura del FE cancello le Linked ed all'apertura
quando le ricostruisco, e per
farlo leggo dal Server il nome delle Tabelle con una connessione
diretta, le tabelle sono sempre AGGIORNATE.
In pratica nel SERVER ho una tabella che elenca le tabelle da Linkare,
dal FE leggo quella ed inizio il ciclo di RELINK, sono 3 righe di
codice...
Quello che hai fatto tu è stato sostituire il vecchio FE(quindi con la
vecchia memorizzazione della struttura) con un nuovo FE che aveva la
struttura aggiornata...
in pratica hai fatto quello che ho detto sopra, ma manualmente...!
Spero di aver compreso bene la questione e di averti dato la
soluzione.
Non ti posto codice, visto che sei tu mi sembra decisamente
assurdo....
Ciao
@Alex

 FE su alcuni client
Ma nel FE effettui il Relink delle tabelle semplicemente oppure non lo
effettui...?
In entrambi i casi il FE ha memorizzato la struttura, ed il semplice
RELINK non la aggiorna, mentre se non effettui nemmeno il RELINK č
altrettanto ovvio.
skip
Quello che hai fatto tu č stato sostituire il vecchio FE(quindi con la
vecchia memorizzazione della struttura) con un nuovo FE che aveva la
struttura aggiornata...
in pratica hai fatto quello che ho detto sopra, ma manualmente...!
Spero di aver compreso bene la questione e di averti dato la
soluzione.
Non ti posto codice, visto che sei tu mi sembra decisamente
assurdo....
Allora Alex, quello che mi segnali mi torna ma fino ad un certo punto o 
meglio non posso crederci:
i miei tool utilizzano una vecchia procedura rivisitata di riallega tabelle, 
mi pare sul sitocomune stava
i FE hanno una tabella con tanti record quante sono le tabelle allegate.
Se l'ultima non č collegata mi fa scegliere il BE e le riallega tutte 
ciclando sulla tabella locale.
Ma solo se c'č errore su quella tabella quindi il solo fatto di sostituire 
il BE nello stesso path non scatena il refreshlink
Sinceramente perň non mi aspettavo che il refreshlink refreshasse anche la 
struttura o le relazioni.
Anche perchč mi č sempre successo che se ho una tabella allegata, se andavo 
nelll'altro database e modificavo la struttura e poi la riaprivo da remoto, 
la modifica alla struttura c'era per bene ed era lě.
Oltretutto sono sicuro che quella particolare tabella non aveva risentito 
delle modifiche fatte sulle altre, quindi non ha senso.
che ne pensi?
Antonio 

 Antonio
Sinceramente non saprei cosa dire...
Io mi sono accorto di questi problemi da quando ho iniziato ad usare
SQL_Server.
In questi casi mi sono accorto che il difetto generato era proprio
quello che lamentavi.
Da li senza tanto pormi i problemi ho modificato il metodo di Relink
nel modo che ti dissi prima... magari lo dettaglio meglio.
Lato Server una tabella con la Lista delle tabelle, la stessa che tu
hai Client_side.
Apri il Client e apro una Connessione al Server(sia SQL o Access non
importa) usando l'oggetto Connection, ed apro un RS puntando alla
tabella che io definisco di Sistema
che mi restituisce sia le tabelle che le Query(quelle pass-Trought).
A quel punto inizio il Loop per le tabelle, ed invece di modificare
semplicemente la proprietà Connect, creo una tabella dall'oggetto
Tabledefs assegnandole il Nome e definendo che è una Linked inserendo
pertanto la proprietà connect.
Per le QueryPT invece rigenero solo la Connect.
Questo metodo è assolutamente esente da qualsiasi problematica legata
al mancato aggiornamento della struttura.
Poi posso concordare con te che possa essere assurdo, ma ho il
sospetto sia un problema del DRIVER ODBC...
Chiaramente su chiusura del Client(la classica Form Hidden che
intercetta l'evento UNLOAD), vado a distruggere le tabelle ciclando
solo quelle con Connect valorizzata, ed eseguo il DELETEOBJECT, azzero
pure la Connect delle Q_PT.
Questo modo mi ha messo al riparo sia dall'anomalia di cui parliamo
che da qualcuno un pò più smaliziato che accede alle Linked....
La procedura di cui ti ho parlato è di semplicissima implementazione,
puoi mantenere buona parte del tuo codice, spostando semplicemente il
reperimento dell'elenco, e modificando con CreteTabledefs invece che
il Tabledefs dovendole ricreare...
Ciao
@Alex

 ha scritto nel messaggio 
news:2b0ea656-3d39-4908...@k22g2000yqh.googlegroups.com...

Non rallenterebbe troppo l'elaborazione?
Già adesso su una rete peciona, per riallegare una quarantina di tabelle ci 
mette una vita
La createtabledef a naso mi sembra più onerosa
Antonio 

 Antonio
Si decisamente, ma se apri una Slash_Form con una Progressbar,
l'utente capisce che il programma sta lavorando per lui...
;-)
Purtroppo o per fortuna io sono uso a CANCELLARE tutte le Linked e
rifarle, ma uso SQL_SERVER... tuttavia il processo di Link credo possa
essere il medesimo...
In un DB di lavoro che ho con una quantità di Tbl simile a quella che
dici, ci impiega 4÷5 secondi a rifare tutto..., ma poi
è una scheggia..
@Alex