Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Cambiare l'ordine dei campi in una tabella Access

Ciao ragazzi e ragazze,
una piccola dritta, credo. Tramite comandi ALTER TABLE aggiungo un campo ad
alcune tabelle del mio db. Questo campo mi finisce in fondo, se vado in
struttura della tabella, č proprio l'ultimo. Siccome questo campo č la
primary-key (contatore), preferirei averlo in cima alla lista.
Tra l'altro, ho il terribile dubbio che alcuni pezzi del programma carichino
piů di una combobox facendo riferimento al campo contatore come
rsTabella(0), quindi č necessario fare in modo che questo campo sia proprio
il primo.
Dall'IDE di Access č possibile modificare l'ordine in qualsiasi momento, per
cui deduco e presumo che sia fattibile anche attraverso codice.....
ne sapete di piů?
grazie, good coding!!!
-- 
Alletun
Sorry, ask me if you want to get my e-mail!

 grazie, good coding!!!
Per Access (per ADO e/o SQL Server non ci sono riuscito, non ho trovato
l'ominima di OrdinalPosition che è la proprietà di ordinamento "fisico" dei
campi, non esposta da ADO) puoi vedere il codice in ESP0DAMA sul SC, quando
il database (Access, appunto), è aperto con DAO.
Attivi il checkbox "Varia", ti posizioni su un campo e clicchi su
"Rinomina", confermi il nome e comparirà la finestrella per la nuova
OrdinalPosition. All'interno del codice vedrai anche come riordina tutti gli
altri campi della tabella.
Vedi poi tu se nel tuo applicativo (o utility apposita) far convivere ADO e
DAO...

 DAO...
ulp, mi sta venendo un colpo. allora, mentre aspettavo qualche post, ho
cercato su msdn e google e ho trovato qualcosa. Effettivamente, usando DAO,
TableDefs e compagnia bella posso agire sulla proprietà OrdinalPosition,
solo che ho rilevato una cosa anomala che mi fa impaurire.
Allora, io ho una tabella con ID e Testo; se vado nella struttura della
tabella, i campi appaiono nello stesso ordine. Ok. Poi lancio una procedura
che cancella e ricrea il campo ID. Il campo ID finisce in fondo.
Quindi se vado nella struttura, vedo l'ordine come Testo e ID. Stessa cosa
se visualizzo il contenuto della tabella. Poi uso DAO e setto
l'OrdinalPosition del campo ID a 1. Se vado nella struttura, vedo la
correzione, ma se vedo il contenuto appaiono ancora nell'ordine Testo e
ID.......
sono veramente impaurito, bel problema.....
bad coding?


 bad coding?
Sģ, OrdinalPosition č in base 0 :-P

 automaticamente in fondo.
uhm, quindi, adesso io creo il nuovo campo facendo alter table, ma non va
bene. Ok, uso DAO.Field, metto l'OrdinalPosition = 0 e funziona: il nuovo
campo è in cima a tutti gli altri.
se che cmq l'ordine con cui appaiono i campi nella struttura è SEMPRE
diverso dall'ordine con cui appaiono nella successiva SELECT * .........
letteralmente AIUTO!!!!!!!
good coding!!!


 ......... letteralmente AIUTO!!!!!!!
Non ti so dire come una Select * ordini i campi, probabilmente ignora
totalmente la OrdinalPosition e li prende come creati/depositati fisicamente
o, addirittura, casualmente. Mi spiace, ma temo che se li vuoi nell'ordine
di OP devi comporre la Select con nomi espliciti in funzione della loro OP.

 di OP devi comporre la Select con nomi espliciti in funzione della loro
OP.
<versi_gutturali>
č quello che temevo. Perň non capisco la logica, sarebbe un milione di volte
piů utile poter settare l'OrdinalPosition per ottenere una SELECT *
nell'ordine con cui voglio io, soprattutto a seguito di una modifica
strutturale della tabella stessa. A cosa serve poter cambiare l'ordine delle
colonne con cui Access scrive nella struttura del db? assolutamente a
nulla.....
:-/
vabbč, grazie Lupo, alla prossima, ora come avrai capito devo sistemare
qualcosina.....
:-\
</versi_gutturali>


 </versi_gutturali>
NomeRusso, hai fatto 30, fai 31: Perchè la cosa ti preoccupa tanto?
Potresti, per favore, farmi un esempio, una situazione in cui l'ordine dei
campi di una "Select *" può creare problemi? Grazie.

 ... triveremme
voleva essere "troverebbe"

 Cercherò, per pura curiuosità, qualcosa che dica che succede in una
"Select *", ovvero quale sia l'ordine dei campi recuperati.
Dai Books On Line di Sql Sever, scheda "Cerca" testo pari a "Choosing All
Columns".
Nell'elenco che ne consegue si trova il titolo preciso che, nella parte
iniziale, dice:
...
When * is used, the order of the columns in the result set is the same as
the order in which they were specified in the CREATE TABLE, ALTER TABLE or
CREATE VIEW statements.
Because SELECT * finds all columns currently in a table, changes in the
structure of a table (adding, removing, or renaming columns) are
automatically reflected each time a SELECT * statement is executed.

 automatically reflected each time a SELECT * statement is executed.
riporto tutto il tuo post perchè mi è poco chiaro.....
la seconda frase dice chiaramente che qualsiasi modifica alla struttura
della tabella influisce automaticamente sulle SELECT * che poi faccio su
quella tabella, o no?
però effettivamente parla di adding, removing e renaming, ma non se cambio
l'ordine  :-(
per l'altra domanda, invece, il fatto è che ho un progetto che per motivi di
prestazioni carica le combobox mettendo l'Itemdata = rsTabella(0) e invece
l'AddItem viene fatto impostandolo a rsTabella(1). Ovviamente parlo di
tabelle semplici con solo id univoco e testo. Attenzione, l'id univoco non è
contatore, e il problema è proprio questo, cioè renderlo contatore.
Per farlo è stato un casino. Questo ID può avere dei buchi, che andavano
rigorosamente mantenuti.
così ho creato un nuovo campo di tipo contatore, l'ho popolato con l'id
corrispondente, ho cancellato il vecchio campo idunivoco e ho rinominato il
contatore come idunivoco. ci sei?
a questo punto però rsTabella(0) mi dà il testo che devo vedere nella combo
e rsTabella(1) mi dà il Long del contatore......bel casino!!!!!!
good coding!!!


 good coding!!!
Prova (scusa se polemizzo, ma lo faccio volutamente) con rsTabella!ID o
rsTabella("ID").
Dimenticaaaaaaaaaaaaaaaaaaa quei numeri!!!!!!!! Assolutamente, sempre e
ovunque!

 ovunque!
sì, sì, lo so, c'hai ragione. Il fatto è che codice di questo non è stato
scritto da me, purtroppo, mi sono ritrovato il codice fatto così. Ovviamente
fino ad oggi ha sempre funzionato, ma che ho dovuto fare questa modifica
alla tabella e son sotto shock....
vabè, grazie Lupo, gentile come al solito!!!


[*Lupo* = 
LupoOrmaiR...@libero.it
 in
news:bnrb24$14prgl$
1...@ID-174464.news.uni-berlin.de
] ha scritto:
Ho voluto provare (solo su db di tipo Access, nella fattispecie 97), sia con
DAO che con ADO.
Ho usato ESP0DAMA.
Un'istruzione del tipo:
    rs.Open "Select * From Tabella"...
tiene conto dell'OrdinalPosition (ovviamente gestibile solo con DAO).
Ripeto, sia con DAO che con ADO.
Quindi semprerebbe Jet a gestirla, (ma a questo punto, se davvero Jet è il
motore, bisognerebbe pensare a VB stesso, salvo che, naturalmente, Jet non
sia solo motore, ma contenga anche un "precompilatore" che, mentre controlla
la sintassi, compone il "vero" comando SQL, esplicito ed esteso,
considerando la OrdinalPosition dei vari campi)
Non ho provato un improbabile (per una Select):
    db.Execute "Select * From Tabella"...