Newsgroup: it.comp.lang.visual-basic
Titolo: Blocco strano

VB6 + Access
Mi va in blocco sia con l'eseguibile che da dentro l'ide quando faccio una 
quey con un predicato ed il database è in rete.
Se mi metto la copia del db in locale va sempre tutto bene.
Mentre se metto il db in rete succede questo:
"select * from fatture" va bene
"select disctint year(datafattura) as......" va in blocco l'applicazione
"select count(...... " va in blocco
"select max(  " va in blocco.
Mi era mai successa una cosa dele genere. Cosa mai potrebbe essere?
Grazie per info
Greg 

 Mi era mai successa una cosa dele genere. Cosa mai potrebbe essere?
Quote del disco o diritti di scrittura.
Perchï¿œ la prima select ï¿œ in sola lettura, le altre richiedono spazio 
tmp (che a dire il vero parlo per altri dbms, con Access non so 
esattamente come faccia, ma ï¿œ plausibile).
Alberto

 
cosa vuol dire 'va in blocco'?
ci sono errori o messaggi?
se attendi qualche minuto succede qualcosa?
magari e' una tabella di grosse dimensioni e l'elaborazione via rete 
richiede piu' tempo di quanto ti aspetti.
che istruzioni usi per eseguire la query?
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 che istruzioni usi per eseguire la query?
L'istruzione è questa:
Set DB = DBEngine.OpenDatabase(xDB, False, True, ";pwd=tsop")
Set RS = DB.OpenRecordset("select distinct year(data) as Anno from posta 
order by year(data) desc")
Dovrebbe dare una tabella di un solo campo con soli 8 records. Si blocca!
Set RS = DB.OpenRecordset("select data from posta")
Questa è sempre sulla stessa tabella, ma va bene, e ritorna migliaia di 
records.
Il database è 10 mega e ritorna tutto in un paio di secondi. 

 
come test, prova a creare nella tabella in questione una colonna 'anno' 
popolata con il valore year(data).
se col mdb connesso via rete fai la query sul nuovo campo invece che sulla 
funzione 'year(date)', il risultato cambia?


 sulla funzione 'year(date)', il risultato cambia?
Adesso non posso farlo, chiuso. Ma aiutami a capire, il test cosa 
dimostrerebbe?
Senza funzioni di mezzo ho gia detto che funziona tutto...
Si inchioda ocn funzioni o ocn query piu complesse su 2 tabelle
-- 
Greg 

 Alberto
La cartella contenente il db � condivisa in lettura scrittura senza alcun 
limite di spazio.
-- 
Greg 

 limite di spazio.
Ok, in realtà pensavo più a particolarità NTFS, comunque se sei sicuro, 
non insisto oltre.
Alberto

 Se mi metto la copia del db in locale va sempre tutto bene.
db in rete + predicato = blocco
queste sono tutte le info che trovo.
m'interessava capire se una query con un qualsiasi filtro funzionasse 
oppure no, dato che nel codice che hai postato non ci sono clausole where 
di sorta.


 where di sorta.
Scusa non sono stato chiaro. Non dovervo dire predicato, ma filtro, quelle 
con filtro non funzionano.
Filtro dato da funzioni; domani provo pure qualche where.
-- 
Greg 

Scriveva greg martedï¿œ, 15/06/2010:

Non ci capisco piï¿œ niente.
Hai fatto degli esempi dove non c'era alcun filtro, ma funzioni di 
accorpamento, dicendo che non funzionavano.
Nelle query da te citate come esempi, la differenza fra quelle 
funzionanti e quelle non funzionanti, ï¿œ che quelle non funzionanti 
richiedono la generazione di spazio temporaneo di elaborazione (nei 
motori 'normali', Access non so esattamente), per cui io mi sono 
concentrato sull'allocazione di spazio.
Ma se sei sicuro che non ci siano politiche NTFS che cambiano le carte 
in tavola...
Comunque la prova ï¿œ semplice: se metti il file mdb su una condivisione 
sulla tua stessa macchina, e ci accedi da rete, o su una macchina 
diversa da quella su cui stai lavorando adesso, hai gli stessi 
problemi?
Alberto

 wrote:
zac
In ordine
- A) "pirlata tua"...sicuro che non ci siano cause di mal scrittura?
Apici pedici pimici pomici?asterischi parentesi non chiuse ...e
amenità varie? In locale funzinano quelle query?
-A-bis) Bug logico...non è che hai messo un on error resume next...ed
è in loop???
Togli tutto e guarda che errore và....un pc freezato non è un buon
segno di programmazione corretta!
- B) "mal configurazione"? non è che la rete è al massimo
dell'accettazione di connessioni di rete? ti ricordo XP pro 10....home
5....una stampante condivisa ne consuma una!....quelle solo in lettura
forse era un caso che funzionassero.....???
-B-bis) strani sw sul pc? un clone di zone alarm che ti blocca alcune
operazioni?
-b-ter)...ma sei sicuri di avere i pemessi di lettura e sopratutto
SCRITTURA????? va che sei un utente PROVENIENTE dalla rete....è un po
delicata la cosa!
USI ntfs vero? su un SO-qualcosa pro vero? non su un SO-qualcosa
Home!???!
c) Eliminato tutto quanto sopra.....errore configurazione driver? ADO
DAO ODBC?
Facci sapere!

 Alberto
No; infatti se metto il db su un'altra risorsa di rete condivisa va tutto 
bene.
-- 
Greg 

 DAO ODBC?
Solo DAO, puro DAO :)
Ciao
Gregorio 


e allora mi sembra ovvio....
quella connessione non esiste....o è fatta male!
prenditi access su un qualsiasi pc che non sia quello incriminato.....
usalo come front-end alle tabelle remote (lo sai fare no....collega le
tabelle esterne sul pc che si blocca)
Lancia poi le query ...se sul pc incriminato tutto funziona...e va
tutto bene!
E' la cosa peggiore: c'è un errore nel tuo programma!Trovarlo ti
obbliga a spulciare tutto!
Se si pianta....allora c'è un errore nelle connessioni di rete (Xp
home ?...permessi non correttamente impostati?)...e sarebbe la
soluzione migliore ...sai dove intervenire!
....p.s.
mi vien in mente....
come colleghi le tabelle remote?
mica con il controllo data access o come si chiamava....???
Fai da codice vero?
Jet 3.5 Jet 4.0 ti ricordi la differenza vero?...access 97...access
2000....mica hai ambedue i jet eh! Eoni fa mi ricordo che su un pc
erano installati ambedue e lui si incasinava ad usare l'uno e l'altro!
....è una vita che non uso più il dao!Ado ti faceva schifo?

 ....� una vita che non uso pi� il dao!Ado ti faceva schifo?
Faccio tutto da codice on jet 3.5
-- 
Greg 


I PERMESSI SAREBBERO MOLTO ALTRO....QUELLO CHE TU DESCRIVI SEMBRA UNA
CONDIVISIONE SEMPLICE di un xpHome (spero non fat32)
cmq
jet 3.5
perchè agganci un access97 vero?
e sul pc incriminato non c'è jet 4 ma jet 3.5 vero?
cmq....posta un po di codice
la connessione
la richiesta
la chiusura
IMHO propendo sempre per una tua cappellata....del tipo...sto facendo
qualcosa e ti è sfuggito di mano quello che faccio!
Considera che sei un utente di rete.....

 la chiusura
tanto per essere chiari
Set DB = DBEngine.OpenDatabase(xDB, False, True, ";pwd=tsop")
non vuol dire un caz de null!
è quello che c'è un xDB che dobbiamo vedere!
e come gestisci le risposte...e le richieste....perchè il tuo
programma va in blocco...ed è stranissimo che non dica assolutamente
nulla!...

 zac
e comunque hai tantissime variabili.....
ad esempio se usi il tuo VECCCCCCCHHHHHIIIISSSSSSSSImo programma
(jet 3.5 è del 1999) su un nuovo pc....potresti avere un dual core (o
più)
ed allora avresti QUESTO tipo di problematica
http://support.microsoft.com/kb/178650/
Però
ADO !!!.....è "secoli"....dai tempi del buon vecchio compianto Lupo
che mi batto per far usare ADO....per tutta una serie di ragioni che
scavando nei meandri della storia del ng (quando ancora ero MMTEX e
Wodka4U) trovi scritto.
A dire il vero è inutile anche ADO ora...sostituito da ADO.net (ma per
collegare postgreSQL i vecchi oledbprovider sono sempre
insostituibili)
Vedere qualcuno che usa ancora una tecnologia del 1999 non mi fa
neanche tenerezza....mi fà pensare che ti devono pagare TANTO BENE per
farlo! Perchè altrimenti sei un masochista puro!

 dice Albe, sembra una qestione di diritti, ma anche no!
Ripeto: verifica la configurazione NTFS, non tanto la condivisione...
Ragazzi, non possiamo utilizzare un database basato su file, pensare di 
usarlo in rete, e non sapere gestire NTFS, eh...
Poi magari il problema è tutt'altro, però...
Alberto

 usarlo in rete, e non sapere gestire NTFS, eh...
SE ce l'ha sotto ntfs!....non siamo sicuri neppure di quello!

 Faccio tutto da codice on jet 3.5
Magari non c'entra nulla, perï¿½ prova a leggere il seguente articolo ed a 
seguire le indicazioni per attivare lo showplan di Jet:
http://articles.techrepublic.com.com/5100-10878_11-5064388.html
Poi fai la query sul db remoto e verifica nel file SHOWPLAN.OUT se c'ï¿½ 
qualcosa di sospetto.
Bye
Raf 

farlo! Perchè altrimenti sei un masochista puro!
Nulla, solo buon cuore.
Allora, aggiorno, soprattutto te ed Albe sulle prove fatte oggi.
Non sono riuscito a sapere su che fat è ospitato il db.
Quindi ho fatto cosi:
sulla mia macchina ho fatto un db vuoto, poi ci ho collegato tutte le 
tabelle e le query contenute nel db in questione.
Apro questo db dal mio pc, vedo tuttti i dati, li posso modifica, lancio 
tutti tipi di queri e risponde.
Riapro il progetto, faccio puntare la variabile che contiene il percorso e 
nome del db a quello sul mio pc
faccio la stessa query appena fatta sul db collegato e il vb non risponde 
piu. Non posso neanche intercettare un errore...
il codice:
Dim xDB as String, DB as Database, RS as Recordset
xDB="E:\vb6\pos.mdb"  (mentre prima era xDB=\\serv\pos-mdb)
Set DB = DBEngine.OpenDatabase(xDB, False, True, ";pwd=pass")
Set RS = DB.OpenRecordset("select distinct year(DataDoc) as Anno from TabDoc 
order by year(DataDoc) desc")
Sulla riga sopra avviene il blocco.
Qui se non ci sono problemi popolo una listbox con gli anni trovati e poi 
chiudo
Seconda prova:
Questa mi fa pensare che il pc con il database access, che quindi fa server, 
portebbe avere qualche  probema strano che vanifica tutto.
Ho provato a scrivere due righe che mandano una copia del db ad intvervalli 
regolari (visto che non ci si puo collegare) all'altro pc e... va in 
blocco!!
Sia con il FileCopy che con il CopyFile, senza dare alcun messaggio di 
errore.
E ovviamente da risorse di rete manualmente si copia senza problemi.
Spero di aver fornito qualche info in piu.
Grazie a tutti
gregorio 

 ha scritto nel messaggio 
news:hvd7h7$jrb$1...@news.eternal-september.org...

Hmmmm... ho un sospetto. Mi è già capitata una roba del genere.
Hai controllato se su serv gira qualche antivirus?
Eventualmente disattivalo (temporaneamente) e se a quel punto il tuo 
programma fila liscio riattiva l'antivirus dopo avergli messo 
nell'ignore-list la cartella che contiene i DB access.
Bye
Raf 

 nell'ignore-list la cartella che contiene i DB access.
Dovrò darci un salto di persona, spero domani o lunedi
ciao
greg 

> nell'ignore-list la cartella che contiene i DB access.
Fatto, disattivato l'antivirus, e gia che c'ero ho compattato il db. Per 
farlo, visto che sulla macchina server c'è office 2003 ho convertito il db 
in Access 2002  compattato e riconvertito in Access 97.
M la situazione è peggiorata.
Adesso il blocco avviene sull'apertura del db invece del recorset, quindi 
molto prima, e segnalando l'errore che il db è aperto in esclusiva, o che 
non ho i diritti.
Provo a raggiungere il db via gestione di rete, e non risco piu a copiare il 
file del database manuelmente, messaggio errore dei diritti. Mentre invece 
ho tutti i diritti.
bah non so piu cosa pensare, comincio a pensare che il db sia corrotto.
Greg

 ha scritto nel messaggio 
news:3ba9f70b-dc8f-402b...@j8g2000yqd.googlegroups.com...

Verificato, fat NTFS senza alcun sistema di quote/disco. Il file può 
crescere fino ad occupare l'intero disco.
greg 

Sembra che greg abbia detto :

Si, ma i diritti NTFS?
Con che utente accedi?
Alberto

 M la situazione � peggiorata.
Rsiloto questo problema;  non avevo i permsessi sul nuovo file, adesso ho 
provveduto a rimetterli.
Tornato alla situazione originale: dal mio posto di utente remoto posso 
aprire il db, fare quesi semplici ma non con funziioni
greg 

 Con che utente accedi?
Con l'utente con il quale mi coleggo, il quale ha i diritti in 
letture/scrittura, controllo completo.
Posso pure cancellare il db, o rinominarlo. A condizione che non ci sia il 
file ldb.
Posso modificare e aggiungere records. Provato adesso, da codice tramite il 
programma.
Non posso fare query un poco complesse, o copiare il file da un posto 
all'altro.
Adesso ho provato, oltre a Copyfile e Filecopy anche con la MS Scripting 
Runtime, la quale copia si il file a differenza delle alte 2 funzioni, ma 
manda ugualmente l'applicazione in stato "Non risponde"
Per non avere altro codice di mezzo ho fatto la prova con un nuovo progetto:
 ecco il codice in form1
Private Sub Command1_Click()
    Dim xDB as String, FileDest as String
    xDB = "\\serv\pos.mdb"
    FileDest = App.path & "\pos.mdb"
    Call FileCopyFSO xDB, FileDest
End Sub
Sub FileCopyFSO(strSourcePath As String, strDestinationPath As String)
    Dim fso As Object, fil As Object
    Set fso = CreateObject("Scripting.FileSystemObject")
    Set fil = fso.GetFile(strSourcePath)
    fil.Copy strDestinationPath
    Set fil = Nothing
    Set fso = Nothing
End Sub
Ciao e grazie per l'aiuto
greg 

 file ldb.
Certo, se c'ï¿œ il file ldb significa che il file mdb ï¿œ in uso.
Il fatto stesso che ti abbia cambiato i diritti del nuovo file, mi fa 
pensare che ci sia l'ereditarietï¿œ del NTFS attiva. Non che sia una cosa 
particolare, diciamo che ï¿œ una variabile in piï¿œ per l'individuazione 
del problema.
Alberto

 problema.
Ha cambiato i diritti al nuovo file, ma colpa mia, poi risolto.
Sono andato al server, ho aperto Access e ho compattato. Distrattamente ho 
accettato che mettesse il nuovo file in documenti dove l'al'tro pc che si 
collega ovviamante non ha diritti.
Poi io ho copiato il file da Dcouemnti nella cartella del programma, e il 
file nuovo non forniva ancora i diritti all'utento remeoto, per 
le'ereditariet�.
Ma poi ho provedduto a ripristinarli manuelmente.
Adesso sono al punto che faccio una copia file con FSO ma poi VB muore.
greg 

 farlo, visto che sulla macchina server c'è office 2003 ho convertito il db
zac
scusa eh...al di là dei permessi....
se hai office 2003
.....come fai ad accederci con jet 3.5 ???
Per me ci stiamo incartando TUTTI.....si fa prima a ripartire da zero!

 Adesso sono al punto che faccio una copia file con FSO ma poi VB muore.
Non so più cosa dirti.
Secondo me è qualcosa legato ad NTFS, è stata la prima cosa che ho 
detto ed è tutt'ora la mia sensazione, però fornisci informazioni 
contraddittorie o incomplete, da qui non riesco ad approfondire oltre.
Alberto

 Alberto
IMHO ha anche un problema di configurazione con l'ambiente!
Se...e ripeto se....(è tutto da interpretare quello che dice !)....
se ha fatto la prova ed io l'ho intesa bene...ossia....
usa access in locale collega le tabelle  in remoto e tutto va senza
problemi....almeno con i permessi "dovrebbe" essere a posto!Altrimenti
l'access locale sparerebbe un bel messaggio di errore!
Quindi il problema...deduco alla Sherlock Holmes.....sta nella SUA
applicazione!
Dove? IMHO sta nell'ambiente che usa...che è incompatibile!
Se usa Access2003 NON può usare DAO 3.5 perchè si ferma ad access 97!
Deve installare il jet 4.0
http://www.daniweb.com/forums/thread25336.html
Quindi per me ha problemi di librerie giuste da "linkare" nel suo
progetto!
Perchè lo deduco?
Perchè un freeze si aveva in genere con le dll incompatibili...
Potresti aggirare il problema lasciando fare il lavoro sporco a
Windows
...sempre per prova e debug!
....usa un collegamento ODBC
....e imposta il log degli errori (è una vita che non lo uso...ma mi
sembra ci sia un flag in avanzate da spunatre)
e poi usalo nel tuo programma!
Odbc dovrebbe essere più rispettoso di DAO e dirti dove esplode!

 Perchè 'ovviamente'?
Perchè...
il mio sistemista del ced, mi ha spiegato che quando con Access 2003 ho 
salvato il nuovo file nella cartella Documenti, questo nuovo file è nato con 
i diritti dell'utente che aveva fatto operazione inq quel momento e basta. 
Anche se poi io l'ho copiato dentro la cartella del programma che mi 
interessa, questo non presentava i diritti in lettura e escittura per nesusn 
utente di rete.
Ma questo, dicevo, l'ho risolto dopo 5 minuti.
Dovresti riflettere sulla prova di copia datta con FSO con progetto nuovo e 
vuoto; il quadro è piu semplice, non ci sono altre cose di mezzo, non ci 
sono veriosni di dao da controllare come giustamente sospetta Wodka,  i 
diritti sembrano ok perche la copia viene effettuata.
Allora perche il vb va in blocco? e va in blocco solo a copiare quel file! 
Possibile che il file contenga dentro qualcosa di corrotto anche dopo la 
compattazione?
Greg

 compattazione?
Un db corrotto avrï¿œ problemi di accesso ai dati, non di copia del file.
Alberto

 Allora perche il vb va in blocco? e va in blocco solo a copiare quel file!
...per mille motivi
spesso il più banale è quello corretto....
non puoi copiare quello che è bloccato da un altro utente!
Che l'utente sia un processo interno di un antivirus ...o l'utente
remoto con cui accedi...pari è!
Scaricati unlocker e prova con quello a vedere che cosa mantiene
bloccato quel file!
A me succede/va con office 2007 e Vista....le stracazzo di
ottimizzazioni di vista spesso mi bloccano la lettera di word in
cancellazione...e spesso è il servizio di indicizzazione files!
Però scusa....taglia la testa al toro!
fatti un DB con una tabella Nome Cognome
mettila in un altra cartella sul server remoto
installa jet 4.0 sul tuo pc di sviluppo
crea una connessione ODBC per il db remoto
Attiva il log errori di ODBC
Usa vb6sp6 per fare una semplice
INSERT  INTO TEST(nome,cognome) VALUES ("pippo","De pippis")
Compila ed esegui
Trappa quello che succede!
Non ci sono storie.....se è una questione di permessi salta fuori
subito...se è una storia di dll...lo stesso!
Quindi ora mi cheto....se hai voglia....IMHO fai
così....altrimenti.....fai come ti pare ! che te devo d'addì! :)

 con cui accedi a NTFS sia lo stesso con cui accedi da rete?
Ma no no, avrò fatto confusione, sono io che mi sposto fisiamente da una 
machcina al'altra, ma macchine e utenti sono diversi.
Sulla macchina A sono utente A, quando mi sposto sulla macchina B sono 
utente B, opero come fossi l'utente B.
-- 
Greg 

 ...per mille motivi
Vodka, letto tutto, attentamente e  taglio tutto per facilitar e la lettura.
- ho disabilitato l'antivirus.
- provato pure l'insert, non via odbc ma con il dao, e va bene
- quando faccio la copia il file non è aperto da nessuno, file .ldb assente.
- CopyFile e FileCopy non copiano, inchiodano senza errori;
- FSO.Copy copia, e subito dopo inchioda senza errori, con progetto nuovo e 
pulito come ho scritto sopra
Mi resta da provare shellexecute e CMD
-- 
Greg 


Ti resta da star calmo e ragionare!
Io non ho la palla di cristallo e non so (ne io ne Albe) cosa davvero
fai!
In base alle tue info ( e ha ragione Albe ...non è che siano coerenti
eh!)
io ho capito:
1) Che da  codice con DAO (che versione non so a questo punto)
ti colleghi ad access(che versione pure non sò!)!
2) Che fai una insert da codice e tutto funziona
In base a questo deduco che come permessi e scrittura file ci siamo!
Cosa non ti funziona?
IO ti avevo consigliato: fattio una tabella TEST (nome cognome)
Prova:
Select nome , cognome From TEST ? Io son convinto ti funziona!
Select nome as MioNome , cognome as MioCognome from TEST ? per me
funziona pure quello!
Select Count(Cognome) As ContaCognomi From TEST ? per me no....se è
vero TUTTO quello che è coerente in quello che dici!
La differenza se è vera dove stà?
Sta nelle stracazzo di librerie che è un sacco di post che ti dico di
controllare....count è una funzione di VBA...e per me hai un problema
di configurazione ambiente: parlate , il tuo vb, e l'access remoto 2
lingue "leggermente" diverse. Vi intendete nell'aprire e chiudere le
porte...ma non vi intendete su quale aprire!
Sempre e soltanto IMHO (ma si fà presto.....basta provare!

 Sempre e soltanto IMHO (ma si fà presto.....basta provare!
Ok, potrebbe essere,  Però non spiegherebbe l'inchiodatura con Filecopy, 
copyfile e FSO.Copy. Qui non c'entra piu il vb, vba, e versioni varie magari 
discordanti. Comuqnue sta tranquillo che non tralascer neanche una parola di 
te e Alby, io poi sono un ruminante :)
-- 
Greg 


Quello è UN ALTRO problema...e anche qui bisogna lavorare di sherlock
holmes.....
sembrerebbe che in uno dei tuoi post tu abbia più versioni di Access!
in uno parlavi che avevi convertito in 2003 compattato e
riconvertito.....
WARNING: mischiare Access diversi è controindicato per la salute dello
stomaco!
Leggi le disavventure di questo tipo
http://database.ittoolbox.com/groups/technical-functional/access-l/access-97-on-win-xp-dll-crash-454127
e quello che dice microsoft
http://support.microsoft.com/?id=241141
FSO ha evidentemente ALTRI problemi!
hai controllato che il file sia chiuso prima di copiarlo?
Hai controllato che non sia in uso?
Hai controllato che non sia troppo grosso?
Hai controllato che la destinazione sia disponibile?
Hai controllato che la connessione di rete sia accettabile (slash
giusti???) ?
Hai controllato che la connesione sia "viva"?
MA SOPRATUTTO
quasi tutti gli antivirus (il 99%) ha il blocco degli script...e se
non è uno script quello che esegui...dimmi cosa lo
è!...pssssst......anche i firewall software o programmi tipo winpatrol
e spybot controllano cose del genere!
Sintesi:
Imho....qui hai un ALTRO problema!
cmq.......
OT OT OTOT OTOT OTOT OTOT OTOT OTOT OTOT OTOT OTOT OTOT OTOT OTOT OTOT
OTOT OTOT OTOT OTOT OTOT OTOT OTOT OTOT OTOT OTOT
tutto codesto casino è un masochismo
per il futuro...............
Vb6(
vb.net
)
ADO
SqlServer Express o MySQL o Postgresql o Firebird  o quellochevuoi
basta che non sia un db basato su file!
Svantaggi:
Pochi....una settimana di tempo per studiare come creare utenti e
ruoli sul db e fare un po di prove!
Vantaggi:
-) Blocca il record invece che la pagina
-) Nessun problema di backup (li fa da se...e quelli più evoluti con
piani sofisticatissimi)
-) Nessun problema a crescere di utenti (mysql postgresql e
parzialmente anche sqlservExpress)
-) Robustezza del db
-) Manutenzione facilitata
-) Hardware ...postgresql mi gira su un notebook con Xubuntu e 256 Mb
ram ...e un altro su un p4 3ghz con windows xp home
se in dao usavi i recordset...simili ci sono anche in ado.....il
cliente non sborsa una lira...pardon Euro!..

 basta che non sia un db basato su file!
Io pensavo a Sql Lite.... per il futuro, ma intanto ho questo prog da far 
vivvere ancora; ormai lavora da 12 anni... e non aveva mai dato problemi
-- 
Greg 

non avrai il db scassato ?