ACCESS: rimozione e aggiunta di record

[Dylan666]

1. Per esercitarmi coi database ho inserito 2 record di esempio: come faccio a cancellarli in modo tale che il conto della chiave primaria ricomincia da capo, cioè da 1?
   
2. Il database dovrebbe poter essere portato avanti su 2 PC, uno PRINCIPALE e uno SECONDARIO. Come faccio a fare che i record immessi nel database SECONDARIO possano essere con facilità (tasto nelle maschera di immissione magari) importati e aggiunti in coda a quelli già esistenti nel database PRINCIPALE?

Parliamo di questo database per l'esattezza, ma anche di altri 2 simili.

[archimede]

Per esercitarmi coi database ho inserito 2 record di esempio: come faccio a cancellarli in modo tale che il conto della chiave primaria ricomincia da capo, cioè da 1?

Devo supporre che:

- stiamo parlando di un campo AutoNumber
- stiamo parlando del caso in cui cancelli tutti i records della tabella

Se così è, non c'è un modo semplice (che io conosca): gli AutoNumber non sono studiati per essere gestiti in questo modo. Il metodo più semplice credo sia cancellare il campo e ricrearlo.

Il database dovrebbe poter essere portato avanti su 2 PC, uno PRINCIPALE e uno SECONDARIO. Come faccio a fare che i record immessi nel database SECONDARIO possano essere con facilità (tasto nelle maschera di immissione magari) importati e aggiunti in coda a quelli già esistenti nel database PRINCIPALE?

Suppongo che stiamo parlando di due PC non in rete. Dici di voler sincronizzare i dati solo dal secondario al primario (non nei due sensi indifferentemente) per cui suppongo che si tratti, ad esempio, di un venditore che va in giro col suo portatile modificando i dati off-line e che quando rientra alla base vuole "scaricare" il lavoro fatto nel db principale. Per questo c'è la Replica: purtroppo non l'ho mai usata, per cui non so darti maggiori info in proposito.

HTH.

Alessandro

[Dylan666]

Sul punto 1 Access la pensa come te:

Dopo aver immesso dati in una tabella, è impossibile modificare in Contatore il tipo di dati di un campo, anche se non vi sono stati aggiunti dati.
Aggiungere un nuovo campo alla tabella e impostare il relativo tipo di dati a Contatore. I dati vengono immessi automaticamente nel campo Contatore ed i record numerati consecutivamente iniziando da 1.

Sul 2 spero di trovare ricca documentazione (l'help dice poco) e di poter integrare il lancio di Replica in un tasto sulla maschera... Ma un questo caso un macro mi potrebbe essere utile?

[archimede]

Sul 2 spero di trovare ricca documentazione (l'help dice poco) e di poter integrare il lancio di Replica in un tasto sulla maschera...

Good luck!

Alessandro

[Dylan666]

È normale che il campo IDscheda dopo l'uso del tasto Replica si trasformi da Contatore Incremento a Contatore Casuale :eeh:

[piercing]

il punto 1 è impossibile... per definizione stessa di campo chiave univoco...

il punto 2 è inutile... forse gestibile con le repliche... ma più probabilmente non gestibile affatto... (non c'è comunque garanzia di coerenza di dati in nessun modo facendo come dici). O lanci due query di accodamento all'interno di un'unica transazione (ti serve come minimo VBA per farlo) oppure è tutto inutile... ma comunque anche così facendo.. se abiliti l'immissione su entrambi i db... gli indici si possono sfalsare ugualmente...

[Dylan666]

Ma non mi sembra tanto strano come caso... Le Repliche vanno abbastanza bene (portano da esempio proprio il caso di un utente con ha il databse sul PC di casa ma lo aggiorna coi dati del portatile) se non fosse per il problema del contatore.

[piercing]

in ambienti monoutente non c'è alcun tipo di problema... è quando gli utenti cominciano a diventare parecchi che il problema si verifica... (e ti assicuro che si verifica.... )

se ha bisogno di un indice numerico uguale basta che ci metti un campo apposito... le chiavi (quindi il contatore automatico come lo chiama access) non le devi proprio guardare ne trattare in alcun modo...


sempre per mia curiosità personale (e perchè come noto sono uno sfascia....) a che servono in questo caso due db uguali?

[Dylan666]

1. Gli "utenti" sono appunto 2 (come nel caso dell'omino con 2 PC)
   
2. Non ho capito cosa intendi per indice numerico...
   
3. NON sono 2 database uguali: c'è quello principiale che può o essere ampliato l'avorandoci direttamente sopra oppure deve inglobare i dati nuovi che mano a mano gleli porta quello secondario. Quello secondario può anche essere azzerato ogni volta, non mi interessa. Serve solo a mandare avanti il lavoro anche in contemporanea con l'immissione nel database principale (in pratica puoi lavorare anche su tutti e 2 insieme ma il lavoro TOTALE resta su uno solo).

[piercing]

Parto dal punto 3:

la tabella di inserimento che quindi fa fede è quella del database principale... giusto? In questo caso basta fare una tabella collegata dal database secondario a quello principale... (ma perchè non usi un DB solo?)

non credo tu voglia fare un qualcosa in cui ognuno inserisce la parte propria e poi debba esistere una funzione di merge dei record aggiunti da ognuno...

Punto 2:

Premesso che le "chiavi primarie contatori numerici" sono intoccabili e ingestibili... puoi creare tu un apposito campo numerico nella tabella che vai a popolare con il numero che dici tu... (ad esempio un recordcount + 1). E'molto difficile da gestire comunque un qualcosa del genere senza creare duplicati. Se fosse facile da fare non avrebbero inventato i contatori automatici....

Punto 1:

Gli ambienti multiutente in un database sono molto particolari a causa della possibiltà di aggiornamento contemporaneo dello stesso record... per fare questo esistono tutta una serie di regole da osservare, prima tra tutte la transazionalità delle operazioni svolte su una tabella...

Esempio:

Utente 1 scrive in Tabella un record e aggiorna in tabella 2 un altro record (legato tramite chiave a tabella 1).

Nel frattempo tra le due operazioni Utente 2 cancella il record appena inserito nella tabella 1. In questo modo possono succedere due cose.... o in tabella 2 viene creato un record orfano, o il database va in errore per violazione di chiave.

Il fatto quindi di eseguire più operazioni senza che nessun altro possa apportare modifiche/cancellazioni è un qualcosa che deve essere gestito via software (generalmente utilizzando le transazioni... la cui teoria è abbastanza ampia e incasinata).

[archimede]

(ma perchè non usi un DB solo?)

non credo tu voglia fare un qualcosa in cui ognuno inserisce la parte propria e poi debba esistere una funzione di merge dei record aggiunti da ognuno...

Mi pare invece proprio questo lo scopo della Replica...

il punto 2 è inutile... forse gestibile con le repliche... ma più probabilmente non gestibile affatto... (non c'è comunque garanzia di coerenza di dati in nessun modo facendo come dici). O lanci due query di accodamento all'interno di un'unica transazione (ti serve come minimo VBA per farlo) oppure è tutto inutile... ma comunque anche così facendo.. se abiliti l'immissione su entrambi i db... gli indici si possono sfalsare ugualmente...

Concordo con praticamente tutto quello che hai detto negli altri messaggi del thread, ma questa non l'ho proprio capita.

La sincronia di db diversi esiste ed indirizza scenari specifici. Quanto sia ben fatta e semplice da utilizzare in Access, ripeto, non lo so ma dire che è ingestibile o inutile non mi sembra corretto.

Certo che se hai difficoltà a fare una maschera di ricerca, forse è meglio andarci coi piedi di piombo con le repliche dei db!

Senza offesa per nessuno, s'intende.

Alessandro

[piercing]

La sincronia di db diversi esiste ed indirizza scenari specifici. Quanto sia ben fatta e semplice da utilizzare in Access, ripeto, non lo so ma dire che è ingestibile o inutile non mi sembra corretto.

ovvio Archi... tu sei abituato ad Oracle... e ad avere un DB su un server che sta sempre acceso....

Le mie domande un pò provocatorie sono semplicemente per capire il problema e mostrare che una replica in questo caso non serve a nulla... generalmente nell'analisi di un problema.. si tende a scegliere strade molto complesse quando la soluzione è molto più semplice...

[Dylan666]

Rispondo in ordine sparso:
il database deve essere per forza sdoppiato in 2 parti (e ri-ripeto che non mi pare tanto assurdo) perché deve poter essere portato avanti da 2 persone su 2 PC, diversi in luoghi diversi ,su materiali diversi dello stesso gruppo, anche se la somma delle voci PC SECONDARIO + PC PRIMARIO rimane solo su PC PRIMARIO.

Sul PC secondario i record non andrannno ne modificati ne canncellati, ma solo messi in lista per essere AGGIUNTI. Il caso che suppone piercing dunque non si pone.
Cioè si lavora su materiali diversi e su una tabella sola, quindi se stiamo facendo l'inventario (mettiamo caso) di libri di una biblioteca ma io ho l'ala destra e lavoro col portatile mentre tu hai l'ala sinistra e lavori col PC fisso, i record orfani o doppi NON si possono creare.

Detto questo, se esiste un modo più semplice delle Repliche per accodare le voci del PC SECONDARIO io sono aperto a tutte le proposte

PS:dato che abbiamo visto che i duplicati non si creeranno mai (nemmeno col contatore automatico, ma vai a convincere Access!), come la mettiamo col contatore?

[archimede]

Detto questo, se esiste un modo più semplice delle Repliche per accodare le voci del PC SECONDARIO io sono aperto a tutte le proposte

PS:dato che abbiamo visto che i duplicati non si creeranno mai (nemmeno col contatore automatico, ma vai a convincere Access!), come la mettiamo col contatore?

Quello che probabilmente piercing cercava di dirti è che, in uno scenario come quello da te descritto, il campo Autonumber lo devi usare (se proprio lo vuoi usare) solo per avere una chiave univoca quick and dirty, ma la chiave primaria reale della tua tabella dev'essere rappresentata da un dato effettivo.

Ad esempio, se parliamo di libri, devi decidere cosa identifica univocamente un libro (ID_Autore+Titolo? ISBN? ...). Questa è la chiave primaria che dovrai usare per identificare il record (anche, e soprattutto, per referenziare il record in altre tabelle, se necessario). A quel punto, inserire i records non duplicati nella tabella del db principale lo puoi fare con una query o poco più (ignorando l'autonumber, che potrà essere diverso per lo stesso record sui due db).

Alessandro

[Dylan666]

Ma ripeto, se l'immissione è fatta da 2 PC su due insiemi con elementi differenti (duplicati IMPOSSIBILI!) e a me l'ordine cronologico va bene come criterio di enumerazione, è possibile tenermi quello come chiave primaria?

A me va bene anche fare in modo che la chiave di numerazione del PC seondario sparisca e si sovrascriva quello del PC PRIMARIO

Esempio:

PC PRIMARIO

1. cane
2. gatto
3. topo

PC SECONDARIO

1. struzzo
2. elefante
3. tigre

PC PRIMARIO AGGIORNATO

1. cane
2. gatto
3. topo
4. struzzo
5. elefante
6. tigre

[archimede]

Se sei SICURO che sul PC secondario non verrà MAI inserito un record già esistente sul PC primario, allora puoi aggiornare il PC primario con una semplice query (ed eliminare i records dal db secondario).

HTH.

Alessandro

[archimede]

(ed eliminare i records dal db secondario)

Oppure mettere un flag o altro segnandoli come già sincronizzati.

Alessandro

[Dylan666]

Assolutamentissimamente sì
Che query si usa e come?

[archimede]

Supponiamo test.mdb con la seguente tabella Tabella1:

- Campo1 (Autonumber)
- Campo2
- Campo3

Faccio una copia in test2.mdb, la apro e aggiungo dei records.

Apro test.mdb e creo un collegamento alla tabella Tabella1 su test2.mdb chiamato, ad esempio, Tabella11.

Ora creo una nuova query:

Codice: Seleziona tutto

INSERT INTO Tabella1 (campo2, campo3) SELECT campo2, campo3 FROM Tabella11;

Et voilà! (Per cancellare i records non credo ci sia bisogno di istruzioni )

HTH.

Alessandro

[Dylan666]

Se chi è stato così gentile da aiutarmi qui mi desse una mano anche al problema linkato sotto gliene sarei molto grato...

http://www.pc-facile.com/forum/viewtopic.php?t=24352