Newsgroup: it.comp.lang.visual-basic
Titolo: [?OT] Cronologia delle registrazioni

Ennesimo OT, mi scuso (anche per la lunghezza), ma, come altri, mi "fido" di
più di questo NG di altri formalmente più specifici.
Devo (!) registrare (leggasi "loggare") _tutte_ le variazioni (in assoluta
cronologia, questa è un'esigenza precisa e irrinunciabile!!!) che le
postazioni di una rete locale possono fare sui _miei_ database.
Per registrazioni intendo, letteralmente, tutte le scritture sui database
(Access o SQL Server) gestiti dalla _mia_ procedura.
Tralasciamo (è davvero marginale) i contenuti di quanto devo registrare,
anche se, in un modo o nell'altro, saranno testi puri.
Sono sincero: da esperienze precedenti (anche se piuttosto antiche e su rete
DOS+Novell) i file Random non mi danno molte sicurezze in ambiente di
multiutenza. Non è il caso di entrare in particolari, ma mi riferisco a
sovrapposizioni, perdita di dati, buffer che si scambiano, etc.
Avevo pensato (per la sua velocità intrinseca rispetto a un database) a un
file Ascii. Pur non avendo esperienza di uso _intenso_ di _grossi_ file
Ascii (pur aperti For Output SHARED), ho la sensazione che, anche nell'arco
di una sola giornata, tali file possano allungarsi al punto da risultare
poco prestanti oltre che problematici dal punto di vista della condivisione
e del mantenimento della necessaria cronologia (quindi garanzia cronologica
delle righe accodate).
Non mi resterebbe (salvo suggerimenti contrari) che una soluzione:
l'ennesimo database (o l'ennesima tabella all'interno di un database
esistente) con un campo testo (o memo se le dimensioni lo richiedono) che
contiene le informazioni di log e di un campo Long autoincrementante (ID)
che mi serva da ordinamento. Una eventuale data e ora sarebbero, per quanto
precise, assolutamente insufficienti per garantire il rispetto della
necessaria cronologia, non fosse altro per l'eventuale (anzi, assolutamente
certa) scorretta sincronizzazione degli orologi delle varie postazioni.
La domanda finale e unica (salvo controindicazioni) è questa: Secondo la
vostra esperienza, posso contare sul fatto che un campo autoincrementante
rispecchia (sia in DAO+Access che in ADO+SQL Server) la cronologia delle
richieste di aggiunte di records, ovvero che un Order By sullo stesso mi
presenti i records stessi nella stessa sequenza cronologica con la quale
sono stati aggiunti? A me, proprio per sua natura e gestione, parrebbe di
sì, ma ... non si sa mai. Grazie.

 postazioni di una rete locale possono fare sui _miei_ database.
non entro troppo nel merito. solo uno spunto:
il proxy wingate fa 2 log.
uno, dettagliato, in txt. con 5 client puo' raggiungere qualche
centinaio di mb in pochi giorni.
quello sintetico, usa un dbf.
ciao

 sì, ma ... non si sa mai.
da un punto di vista dell'autoincremento non dovresti avere problemi,
ma se deve registrare molte operazioni, tanto da non rendere convenienti
i file di testo, con access, non rischi la stessa cosa?
--
bye BlackMagic
ICQ#:85485468

 i file di testo, con access, non rischi la stessa cosa?
No, Access va benissimo! Sono serissimo! ;-)
Le operazioni che devo registrare (ovviamente in aggiunta) sono esattamente
il numero delle operazioni che già registro con l'applicativo. Sono (senza
gli effetti e aggiornamenti che presumono) uno "specchio" delle normali
operazioni già previste.
Se va tutto bene da anni (tranne qualche caso eccezionale dovuto a incidenti
ambientali), perchè non deve continuare a farlo? ("Obsolescenza programmata"
e gufate tremende... permettendo)

 sě, ma ... non si sa mai. Grazie.
in generale direi proprio di si... c'e' stato un thread qualche anno fa
relativamente ai campi Identity di Sql7 che qualche problema avevano
sollevato.... resta comunque il problema che prima o poi la tabella la devi
svuotare, e probabilmente con criterio FIFO e puoi rischiare di andare fuori
range, specialmente se hai un elevatissimo numero di transazioni.....
usando solo getdate() dovresti starci senza problemi, anche come
ordinamento...
che te ne pare??
Andrea Montanari
montanar...@virgilio.it
http://www.asql.biz/DbaMgr.shtm
DbaMgr2k ver 0.2.0  -  DbaMgr ver 0.48.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
--------- remove DMO to reply


la mia considerazione era dovuta al fatto che se registri tutto
registri anche 'delete' e 'update' (le semplici interrogazioni spero di no),
quindi in questa tabella il numero di record
andrà sempre ad aumentare, poi devi decidere come registrare le
informazioni,
anche se credo che costruirai una stringa sulla base dell'operazione che
stai
facendo, se usi i metodi di un oggetto recordset, oppure direttemente la
stringa
SQL se usi un metodo execute, comunque per qualsiasi operazione fatta
avrai un record in una tabella, io mi riferivo alle dimensioni
che questa tabella puo raggiungere un breve tempo, dato che hai un campo
contatore di 4byte + un campo testo/memo di n caratteri, fai un pò di conti
per vedere quello che può succedere.


Ringrazio tutti per i sempre utili suggerimenti, ma vorrei riportare il
quesito nella sua banalissima realtà:
L'autoincrementante è affidabile?
Ribadisco le "condizioni irrinunciabili":
-Devo rispettare la cronologia delle aggiunte in rete (mi riferisco ai
record  che aggiungo, non al significato "logico" dei loro contenuti, quindi
AddNew, sempre e soltanto)
-E' assolutamente marginale (comunque gestito dalla logica dell'applicativo)
cosa, quando e come devo registrare
-Le dimensioni che la tabella (o il file) può raggiungere non sono
fondamentali: Quando fossero troppo onerose, si scarica (con procedura
esterna e autonoma, con archivi congelati) e si riazzera, ricreando la
tabella e quindi riazzerando l'autoincrementante.

Se usi sqlserver la cosa è più che ottima ... gli
autoincrementanti di sqlserver sono efficenti
tanto quanto quelli di oracle ...
Però se il tuo progetto è su access e vuoi implementare
solo sta cosa su sql server non ne vale nemmeno
la pena.
Ciao
Andrea

 la pena.
Non ho capito :-(
Io devo fare qualcosa che funzioni sia su Access che su SQL Server.

 ha scritto nel messaggio
news:avi052$fssjv$1...@ID-174464.news.dfncis.de...

E questo è un male...
No, scherzo...
Diciamo però che con Access, i problemi sono diversi: intanto, il lock della
tabella del log potrebbe far sì che due client si 'superino' nell'ordine in
cui eseguono l'update, e, per le ben note problematiche di scarsissima
affidabilità delle transazioni in Access, non è neppure garantito che ad
ogni update sia registrato l'evento nel log.
Con Sql-server, la cosa è estremamente più sicura: l'autoincrementante è
affidabilissimo, per data ed ora puoi usare l'orologio del server (quindi
avresti una sequenza temporale con relative differenze di tempi realistica),
e soprattutto le transazioni ti garantiscono che 1 Update = 1 voce di Log.
Per l'operatività, hai due strade fondamentali:
1) Per gli update che devi loggare, usi una stored procedure. All'interno di
essa, vai a reperire il valore precedente, effettui l'update, ed archivi nel
log i due valori (vecchio e nuovo), oltre ovviamente a data, ora, client e
numero sequenziale. Io di solito agisco così.
2) Usi un trigger. Io li uso poco, troppo poco, ma chi ne fa uso è
contentissimo.
La soluzione del file di testo è poco praticabile. Le problematiche di
sincronizzazione fra client, e di concorrenza e sincronia fra accesso al txt
e al db sono troppo 'a rischio'.
Ciao
Alberto

 numero sequenziale. Io di solito agisco così.
Non volevo recuperare niente, nè usare data ora, ma solo fare rs.addnew,
rs!testo="...", rs!update e affidarmi all'autoincrementante per la
cronologia in una Order By successiva.
Mi rendo conto di aver scritto molto, anzi, troppo, visto che non sono
riuscito a spiegarmi. Sorry :-(

 L'autoincrementante è affidabile?
Secondo me è meglio che non ti fidi della teoria e lo provi tu. Scrivi un
programmino che si limita a scrivere in un record di MDB (con campo
autoincrementante) un semplice valore che legge da un ini, e poi scrive lo
stesso valore anche in append ad un file di testo. Lo piazzi su 3 diverse
macchine e metti nei 3 ini 3 valori diversi (1, 2 e 3). Lanci il programma
sulle 3 macchine e dopo un pò blocchi per rianalizzare i due file e vedere
se effettivamente non si è perso l'ordine delle modifiche.
Il problema è che se scopri che l'autoincremento non segue la corretta
logica (magari per problemi di cache locale) ti salta tutto il concetto
della faccenda. Anche se utilizzi un file di testo in append, come fai a
sapere in che ordine sono salvate sui file modificati le modifiche lanciate
quasi contemporaneamente da due macchine? Se access usasse la cache per la
tabella autoincrementante, la userebbe anche per le normali tabelle di
lavoro che modifichi.
Secondo me, inoltre, se il problema è l'occupazione di spazio, il file
sequenziale è premiante rispetto all'MDB. Qualunque cosa ci scrivi occupa di
base lo spesso spazio, ma l'MDB si porta dietro il suo overhead di sistema.
Ciao
*Roby*

 base lo spesso spazio, ma l'MDB si porta dietro il suo overhead di
sistema.
No, non è lo spazio, ma il rispetto della cronologia delle varie operazioni
in rete. se diventa troppo grosso riduco la frequenza di scarico, non è un
problema. Vero che il database, a parità di info, occupa molto più spazio,
ma era l'unico modo (sfruttando l'autoincrementante) di avere la cronologia.
E' chiaro che potrei crearmi un contatore, bloccarlo, leggerlo,
incrementarlo, assegnarlo, scriverlo e sbloccarlo ogni volta, ma volevo
evitare queste fasi piuttosto pesanti rispetto a quelle (già pesanti, in
aggiunta a quelle già previste dall'applicativo) di puro log.