Newsgroup: it.comp.appl.access
Titolo: id contatore raddoppiato

Help! Mi sono ritrovato una cosa stranissima.
In una tabella ora esistono due records con lo stesso Id che č chiave 
primaria e contatore.
Non posso chiaramente modificare manualmente la chiave e le modifiche fatte 
su un record vengono immediatamente riconosciute dall'altro avente lo stesso 
ID.
Non so assolutamente come ciň possa essere capitato siccome l'inserimento 
avviene tramite forms non associate e addnew di dao, previa verifica del 
numero protocollo max inserito +1
E' sintomo di corruzione? Devo ripristinare il backup?
me la sto facendo ...sotto...
-- 
ciroteo
MC
il mio primo aforisma ...
"Se la conoscenza puň creare dei problemi, non č con l'ignoranza che
possiamo risolverli"
Isaac Asimov 

 -- 
Infatti come volevasi dimostrare ... db corrotto! #errore #errore #errore .
tutti i records inseriti successivamente sono andati persi, ha perso la 
chiave primaria.
soluzione: ripristinato backup di ieri sera. Quello di mezzogiorno non era 
ancora partito.
ripropongo il tema:  in multiutenza passare ad un altro motore o ottimizzare 
il data entry? Se scelgo la seconda soluzione oltre a forms non associate e 
all'utilizzo di dao che posso fare?

 me la sto facendo ...sotto...
Se vuoi qualcuno qui ti puň fornire una piscina..
-- 
_ _
Ciao
MAssimiliano Amendola            
www.accessgroup.it
Cisa - Conferenza Italiana per Sviluppatori Access
Info:  
www.donkarl.com/it


Sistema prima le schede di rete.


 all'utilizzo di dao che posso fare?
Non facciamo confusioni: gli oggetti di Access "associati" funzionano
benissimo e problemi del genere puoi averli con qualunque metodologia
d'accesso ai dati tu scelga ... in configurazione file-sharing.
Soluzioni:
1) Affidarsi alla buona stella (e alle schede di rete come ti ricorda MA).
2) Configurare le applicazioni in rete con un Terminal Server, se ci sono le
condizioni aziendali per farlo.
3) Optare per MSDE o SQL Server o MySQL per l'archiviazione, anche con
comode connessioni ODBC.
Ciao.

 -- 
metterň gli occhialini ... mi dicono che sia un po' torbida!


dici di controllare l'ultima postazione che ha inserito il dato valido? 
potrei vedere sia quello valido che quello successivo.
In realtą il primo dato corrotto veniva visualizzato sul pc di chi ha 
inserito ma poi non si vedeva sul BE che aveva per l'appunto perso la chiave 
e gli altri records successivamente inseriti.

 mumble mumble ... non so proprio come fare.
Non lo condanno affatto: semplicemente, come tutti i file-sharing, è esposto
a problemi del genere in ambiente LAN.
Problemi per la verità non frequenti con un briciolo di fortuna.
D'altra parte non è questione di opinioni personali ma di architettura.
Ciao.

"Oscar Manfredini" <osca...@XXX.it> ha scritto nel messaggio 
news:Nf8ze.4278$tX6....@twister1.libero.it...

Certo sono sicuro che non siano opinioni personali, cercavo per l'appunto di 
capire attraverso le esperienze altrui quale fosse una soluzione che non 
cercasse solo nella fortuna la risposta.
L'argomento dell'utilizzo in ambiente multi utente è stato più volte 
sviscerato. Io avevo trovato da tempo una struttura che funzionava, ora 
proverò a vedere nei vecchi 3d se qualcosa mi è sfuggito.
Grazie.

 Grazie.
Non credo ti sia sfuggito molto, Oscar ti ha esposto
con chiarezza non tanto il livello di JET, quanto il
limite di applicazioni Multiutente basate su JET in LAN(TS a parte).
La corruzione del BE è sempre in agguato.
Io ho lavorato per 4 anni con un DB abbastanza grosso in multiutenza
con circa 15 utenti(non contemporanei, mediamente erano 3/4) e non
è mai successo nulla, ma concordo con Orscar che la fortuna sia
uno dei motivi.
Da un'anno uso SQL_SERVER apportando pochissime modifiche al
FE, in quanto inizialmente per motivi di tempo non potevo
riprogettare il DB, quindi Linkando via ODBC(DSN_LESS).
Saluti.
@Alex
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG


[inside OT]
bentornato era un po' che non ti leggevo. passato bene le ferie? dove sei 
stato di bello? 

 proverò a vedere nei vecchi 3d se qualcosa mi è sfuggito.
No, evidentemente non ti è chiara la base del discorso e perchè ho tirato in
ballo la fortuna.
Allora, in modalità file-sharing il motore dev'essere installato su ogni
postazione di lavoro.
Quando uno o più record(s) devono essere memorizzati in una tabella, il
pacchetto di dati viene trasferito dal Client al File-Server.
Se per ragioni ambientali (problemi di LAN, Hub, schede di rete, sbalzi di
tensioni, Clients che si spengono o ballano la samba) il pacchetto in
oggetto si "corrompe", sul DB condiviso verrà scritta senza alcun controlo
robaccia.
Da qui nascono le corruzioni dei DB ed è un fenomeno possibile per tutte le
architetture file-based, non Jet in particolare.
Converrai che all'aumentare dei Clients aumenta la probabilità che qualcosa
non vada per il verso giusto (basta una scheda di rete o un Client a guastar
la festa), inoltre non puoi mettere sotto gruppo di continuità tutti i PC
della rete per ragioni pratiche e di costi.
Capirai quindi perchè ho usato la parolina "fortuna".
Con un Server SQL cambia tutto: i Clients non spediscono pacchetti di dati
al Server SQL, ma "istruzioni" SQL da eseguire per effettuare l'Insert
Update dei dati.
Queste istruzioni vengono interpretate dal Server RAM resident ed eseguite
(se comprensibili) sulla macchina Server.
Quindi, se il PC Server è protetto da sbalzi di tensione (e funziona bene) è
molto improbabile che si verifichino corruzioni dei databases,
indipendentemente dal numero di Clients collegati.
Con la logica Terminal Server, in qualche modo anche Jet (pur senza log
delle transazioni e con molte limitazioni rispetto a un Server SQL) lavora
in modalità "Server" rendendo improbabili problemi sui dati.
Spero d'aver chiarito la situazione.

 metterò gli occhialini ... mi dicono che sia un po' torbida!
Il boccaio e mollettine per il naso no? De gustibus!
Ciao.
-- 
Sergio MAZZA 

Oltre a quello detto da Oscar e da altri (affidabilita' ret/pc), ti posso
solo consigliare di lavorare su tabelle locali da scaricare poi sul db
centrale al termine delle elaborazioni.
Io ho eliminato anche tutti i campi memo, un'abitudine che mi porto dietro
dal vecchio access2
Ciao
mau_rizio
-- 
Ciao
mau_rizio
---
Datemi una mano, facciamo qualche scambio :)
http://www.freemao.com
(siccome qualcuno ha detto che avevo troppe paggggine, ho unificato il
tutto :))
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

"Oscar Manfredini" <osca...@XXX.it> ha scritto nel messaggio 
news:dZ8ze.4392$tX6....@twister1.libero.it...

Ovviamente! 

 dal vecchio access2
Lungi da me voler far polemica su questo tuo consiglio: ma anche questo
suggerimento non sposta di una virgola il problema.
A parte che se si ha l'accortezza di settare a "ottimistico" il blocco dei
recordset(s) associati alle Forms, le prestazioni in multiutenza del data
entry e l'impegno della rete sono irrisori
E comunque la soluzione che consigli complica la programmazione e allunga di
molto i tempi di sviluppo, diminuisce "lo stress" sul Db condiviso in fase
di Data Entry (rispetto al blocco pessimistico sulle Forms) ma lo aumenta
all'inverosimile in fase di Update Batch dei Records dal Client al Server.
Quantomeno proprio nel caso che si sta discutendo: molti PC concorrenti in
rete.
Conosco bene, purtroppo, la configurazione che hai citato perchč era quella
la logica adottata dalle procedure sviluppate nell'ente pubblico in cui
lavoro, prima che cinque anni fa si rifacesse tutto appoggiandosi a SQL
Server.
Sul discorso campi Memo hai senz'altro ragione: varie tipologie di
corruzioni sono legate ai suddetti (molto ben documentate da MS).
Ciao, Oscar

 corruzioni sono legate ai suddetti (molto ben documentate da MS).
Hai qualche link a documentazione on line su questa cosa? 


 stato di bello?
Si ho approfittato del periodo premanutentivo(nel quale non faccio
ferie) e sono andato all'ELBA per 2 settimane, proprio quelle
in cui il caldo imperava, ed io sguazzavo...! ;-)
Scherzi a parte sono stato fortunatissimo a beccare 15gg di bel
tempo.
Ciao(Congratulazioni per quanto di nuovo ho saputo)


 Hai qualche link a documentazione on line su questa cosa?
Per esempio questo:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q303528
In rapporto al discorso Memo, non c'č molto da dire: giŕ dai tempi dei
Service Pack per Jet 3.51 la documentazione acclusa faceva riferimento
esplicito a corruzioni di campi Memo (memorizzati in aree separate).

Quello che mi dici mi ha sinceramente incuriosito, dovro' fare qualche
prova...
magari ci risentiamo in futuro.
ciao


 ha scritto nel messaggio
news:18d992694d791daf71...@mygate.mailgate.org...

Grazie Alex.


non disputandum est ... o disputandum non est?


Avvocatooo... Lo vedi, qui mi si offende!!!
Ciao.
-- 
Sergio MAZZA 

 non disputandum est ... o disputandum non est?
la prima [perifrastica passiva], o citazione ancora piů dotta
"non est sputazzellam..[Totň]"



e li ci vai a nozze.