[Access 2007] Aggiungere contatore con i record ordinati secondo un campo esistente

[borgata]

Il titolo dice più o meno tutto.

Ho una tabella (contenente circa 2500 record con una decina di campi di cui una parte con riferimenti esterni) a cui vorrei aggiungere un ulteriore campo contatore in maniera tale che questo risulti ordinato in base ad una (o meglio, due o tre, campi già esistenti).

Ho provato a farlo in modo "semplice", ma l'ordine non è quello desiderato: ordinare la tabella prima prima di aggiungere il campo non serve a nulla.

Il problema di base è che non posso sconvolgere il database, quindi escluderei la possibilità di ricreare completamente la tabella.

[LoryOne]

Per quel che ne so, il campo contatore è un campo intero lungo progressivo che fa riferimento al numero di record, ossia di righe. Proprio per questa sua caratteristica, è utilizzato preferibilmente come chiave primaria.
Potresti creare un'ulteriore tabella ordinata in base ad una query order by [having] (insert into tabella select ... from ... [where] order by .... [having]) che comprende già il campo contatore che viene incrementato automaticamente; poi eliminare la tabella originale ricreando le eventuali relazioni tra tabelle.
In pratica, fare quel che vuoi evitare.
Nel caso decidessi di procedere, annotati non solo le relazioni, ma anche le eventuali operazioni di aggiornamento/cancellazione ad esse associate e che il motore Jet esegue automaticamente, una volta impostate.

[borgata]

Esatto... proprio quello che averei voluto evitare

Possibile che non ci sia un metodo semplice per aggiungere un campo contatore con i record ordinati come voglio senza dover ricreare la tabella?

[LoryOne]

Mi sa di no.
L'ordinamento della tabella agisce solo sulla visualizzazione dei dati ed il campo contatore è un progressivo numerico. A lato pratico non ti cambia nulla quando esegui la query in base alle relazioni predisposte ed all'integrità dei dati.
Se vuoi "cambiare" l'ordinamento crea una query secondo le tue esigenze ed associa il recordset in visualizzazione.

[borgata]

In realtà la situazione è un po' più complicata, i dati sono gestiti da una maschera per gli inserimenti manuali e mi serviva li una singola colonna che potesse anche darmi l'ordinamento che mi serviva (anche se poi lo scopo del campo contatore è un altro).

Ho provato a ricreare la tabella ma ho perso qualcosa per strada, ora devo capire se e come posso riparare.

[LoryOne]

Cosa avresti perso, dati, relazioni, strutture, associazioni ?

[borgata]

Al momento ho notato che usando la maschera la data di inserimento non viene più aggiunta automaticamente quando inserisco manualmente gli altri dati.

[LoryOne]

Beh, controlla le proprietà del campo in tabella al quale l'oggetto è associato.
Fai in modo che le proprietà dell'oggetto associato ricalchino quelle del campo in tabella.
Poi controlla (o meglio ricrea) le relazioni di connessione fra maschere in fase d'inserimento, ossia ridefinendo quali campi sono connessi tra loro tra le "eventuali" maschere nidificate.
Purtroppo, se modifichi una maschera in relazione con una tabella e se quest'utlima non esiste più o viene ricreata anche con nome identico, le relazioni tra maschere non sono ripristinate coerentemente.
E' un "problema" minimale, cio che importa è la struttura del database con le relazioni ed operazioni associate in cascata.

[LoryOne]

L'integrità dei dati e le relazioni tra tabelle evitano l'incoerenza delle informazioni correlate fra tabelle distinte.
E' un aiuto notevole nei confronti del programmatore, poichè lo manleva da dover definire le verifiche sulla coerenza direttamente nel codice, limitandosi a gestire l'eventuale errore generato; infatti, anche se il DB non fosse relazionale, affinchè l'applicativo gestionale funzioni regolarmente, tali verifiche devono necessariamente essere apportate all'interno del codice dell applicativo in modo da renderlo affidabile. Pertanto, relazionale o no, ai fini pratici un DB (volenti o nolenti) lo è sempre e comunque.
Quando hai a che fare con i relazionali, considera che crearli tali implica a monte uno sforzo da parte del "progettista" del DB che si traduce nella definizione preliminare della sua intera struttura; La definizione delle maschere d'inserimento è una fase successiva e non deve inficiare sulla fase precedente.
Se cio avviene, a seconda dell'entità della modifica apportata alla struttura delle tabelle, devi riprogettare la fase di immissione attraverso le maschere.
Per tale motivo, se l'operazione che devi apportare ti sembra "facile", ti capaciti del perchè non si riesca senza dare vita ad ulteriori problemi

[borgata]

Il problema di fondo è che non riesco ad accedere alla struttura della maschera, ed è questo il motivo per cui volevo evitare di ricreare la tabella.

Giusto per non lasciare nulla di intentato, puoi scrivermi la sequenza passo passo per accedere alla struttura della maschera?
Non vorrei essere io a sbagliare qualcosa, data la mia conoscenza limitata di Access.

[LoryOne]

Devi andare in visualizzazione struttura.

[LoryOne]

...non è che puoi postare un'immagine di come ti si presenta il DB ?

[borgata]

La visualizzazione struttura non è selezionabile, è in "grigetto". Qualche idea su come renderla accessibile?
Che immagine vorresti, esattamente?

[LoryOne]

No, nessuna immagine, mi hai già risposto.
E' in grigetto perchè disabilitata in runtime.
Quali sono le voci di menu alle quali puoi accedere ?

ps: E' un DB fornito "as is" quindi l'autore ha volontariamente impedito la modifica della struttura.
Contattarlo ti viene male ?

[borgata]

No, dovrei poterlo contattare, e dovrò farlo.
Non so però quanto sarà collaborativo a riguardo

A quali voci posso accedere? Solo l'apertura della maschera.

Ma poniamo il caso in cui l'autore non abbia volontariamente bloccato la modifica della struttura della maschera, è possibile magari riuscire a riabilitarla? Chessò, per esempio si tratta solo di selezionare una qualche opzione che non è stata "protetta".