Newsgroup: it.comp.lang.delphi
Titolo: D2006 - Visualizzazione dati

Ho un ulteriore "rallentamento" in una web application...
Ho una pagina di Login e una di registrazione. In quest'ultima l'utente si
registra (utilizzo l'ashing per salvare la password insieme allo UserID nel
DB Access).
La tabella di registrazione č semplicissima:
CAMPO INCREMENTALE ID - USER ID - PASSWORD
Quando un'utente fa il login verifico i dati e gli visualizzo la sua pagina
personale.
I dati personali sono memorizzati in altre tabelle che hanno in comune con
la tabella di Registrazione l' ID.
In sintesi l'utente Pippo con ID = 10 avrą i suoi dati nelle tabelle con ID
= 10 (che gattata! :-)  ).
Nel codice utilizzavo l'ID di registrazione per reperire i dati nelle varie
tabelle semplicemente indirizzando "il cursore" alla ROW desiderata:
dsAdapt.Tables[0].Row[ID]
finchč non mi sono accorto al controllo dei dati che certe volte qualcosa
non quadrava.
Nel DataAdapter Configuration se eseguo un *Preview Data* mi ritrovo i
record mal ordinati.
Ad esempio, di seguito:
da 1 a 96 poi
da 145 a 192 poi ricomincia da
97 a 206
quindi quando ID = 97 l'applicazione mi restituisce i dati dell'utente 145
Al momento ho aggirato il problema scandendo le tabelle "alla ricerca"
dell'ID che mi occorre e leggendo i dati del record corretto ma non capisco
il motivo di questo ordinamento random.
Avete qualche idea?
Valter

 dsAdapt.Tables[0].Row[ID]
L'ID è un campo autoincrementale, quindi ha un valore che non può essere 
utilizzato per indicizzare una riga appartenente all'insieme delle righe 
contenute nella tabella, non fosse altro che l'ID autoincrementale, per 
sua stessa natura, lascia volutamente dei "buchi" quando si aggiungono e 
si eliminano dei record.
Occorre mettere in relazione i valori dei campi di due righe, e non i 
campi di righe prelevate usando l'ID come indice.
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)
Inviato da X-Privat.Org - Registrazione gratuita 
http://www.x-privat.org/join.php

 si eliminano dei record.
Scusa, mi è partito come msg personale...
Si, il concetto è chiaro ma io partivo dal presupposto, anzi certezza, che
nel db non si sarebbero mai verificate eliminazioni di record e che gli
utenti aggiunti avrebbero sempre preso l'ID successivo.
Comunque nel mio caso l'ID è incrementale solo nella tabella Registrazione
(nuovo utente).
In ogni caso non piaceva neanche a me :-)
Quello che però vorrei capire è perchè se apro la tabella in Access i record
sono sequenziali e se invece li visualizzo dal DataAdapter assumono la
sequenza che ti ho citato...
Ciao
Valter

 sequenza che ti ho citato...
E' possibile che Access effettui un ordinamento autonomamente.
Se vuoi applicare un ordinamento, fallo direttamente nella query SQL che 
ti restituisce i dati, con la clausola ORDER BY.


 contribuire a stabilire legami con altre tabelle.
Marco, faccio fatica a capire quale problema potrebbe presentarsi
utilizzando l'ID, almeno per come è concepito il mio codice.
l'utente si registra e le sue User ID e Passw vengono memorizzate nella
tabella Registrazione, accompagnate da un ID univoco generato
automaticamente.
Contemporaneamente creo un nuovo record nelle tabelle dei dati personali
(che sono due) inserendo l'ID manualmente in un campo di tipo testo. Questo
dato sarà sempre univoco perchè creato in autoincremento durante la fase di
registrazione.
Successivamente, quando l'utente effettua il login, "cerco" il suo User ID
nella tabella Registrazione, confronto la pass e se tutto corretto leggo
l'ID relativo...quindi accedo alle tabelle dei dati semplicemente puntando
all'ID (campo testo) che mi restituisce il record dell'utente loggato.
E' sbagliato?
Ciao
Valter

 Valter
Andrea

 Si, perché compari le stringhe(nel campo testo) e non i numeri.
...era inteso che prima del confronto permuto l'ID in stringa!
:-)
Forse mi sono spiegato male...l'applicazione ora, cambiando il metodo di
ricerca nel db come discusso nei post precedenti, funziona correttamente.
Il fatto che confronto due stringhe è solo una preferenza a livello
personale ma supponendo comunque di comparare dei numeri mi chiedevo dove la
struttura del codice risultava non corretta dal punto di vista di
Marco...(ovviamente sono interessato anche alle tue impressioni).
Ciao
Valter

 Marco...(ovviamente sono interessato anche alle tue impressioni).
Confrontare come stringhe due valori entrambi interi non è necessario, e 
questo è senz'altro una parte da correggere... perché farlo?
In secondo luogo, quello che "contestavo" era l'uso dell'ID per 
indicizzare una determinata riga: non è detto che il record con indice X 
(nella collezione dei record reperiti) abbia un ID equivalente a X.
In ogni caso, per la tua esigenza non hai nemmeno bisogno di scandire 
record in quanto dovresti sempre avere a che fare con uno ed un solo 
record di registrazione, quello che corrisponde ad un determinato ID, o 
ad un determinato utente e così via, filtrati direttamente attraverso la 
query SQL e l'uso di parametri.


 Valter
Andrea

 Prova a confrontare 1234 con 00001 come stringhe...
non capisco davvero cosa mi vuoi comunicare...
a prescindere dalla inutilitą reale di compiere l'operazione di conversione
in stringa dell'ID quest'ultimo sarą sempre un numero intero e senza zeri
davanti...
dunque 1234 = 1234 come '1234' = '1234'
e '1234' <> '00001'
ti puoi spiegare meglio?
Ciao
Valter

 Valter
Andrea

 Che risultato ti aspetti tu?
ah, parlavi in senso generale...
ma nello specifico del thread in oggetto si parla di eguaglianza
Ciao
Valter

 davanti...
Sì, questo è vero, diciamo che nel caso in esame la diversità dei tipi 
che vengono confrontati è ininfluente; tuttavia, essendo una conversione 
non utile, non vorrei mai che questo nascondesse altri problemini che 
poi danno luogo ad effetti collaterali.
Al momento attuale, non ho ben capito se hai risolto i problemi che 
avevi o se ci sono ancora delle imperfezioni; in ogni caso, se vale la 
prima condizione, cerca sempre di postare anche il codice significativo 
del passaggio così da riuscire a comprendere meglio la situazione anche 
a livello pratico, oltreché teorico, e apportare le dovute correzioni, 
ammesso che siano necessarie.


 avevi...
si, grazie Marco, effettivamente ci si stava perdendo.
Sto rivedendo l'estrazione dei dati dai record personali dell'utente...
come da te suggerito anzichè scandire tutti i record userò una query (devo
vedere come, se ricordi ho sudato un pò a lavorare sul database di
un'applicazione web - ne vengo dai classici edit, insert, post ecc...).
L'unica cosa che ancora non mi spiego, nonostante sia con la scansione sia
con la query non è più vitale, è perchè il preview data del Data Adapter mi
visualizza i record non ordinati per ID (per inciso proprio quello numerico)
ma a gruppi, es: da 1 a 96 poi da 145 a 192 poi ricomincia da 97 fino al 144
e da 193 a 206...come puoi vedere i record ci sono tutti ma a blocchi
sfalsati...come già detto nel db Access i record sono ordinati
numericamente, ho verificato che l'ordinamento del Data Adapter non segue
nessun filo logico (vedi nome utente o pass ordinati alfabeticamente) e non
è solo una questione di visualizzazione perchè se scansiono la tabella
partendo dal primo record e leggo il contenuto del record 97 mi vengono
restituiti i dati del record con ID 145 cioè proprio il 97° della lista così
come presentata dal Data Adapter...
E' proprio questa curiosità che non vorrei mi creasse successivamente grossi
problemi...
Può essere utile riferirti che a livello test ho scritto un'applicazione in
Win32 che crea blocchi di utenti a piacimento (per non dover via web
inserire uno per uno gli utenti virtuali)...ad esempio inserisco nel db in
un colpo solo 70 utenti, poi via web altri due, poi di nuovo 50 e così
via...può esserci una relazione?
Ciao
Valter

 [...]
Può darsi che ti vengano visualizzati in ordine di inserimento.
Ad ogni modo, la visualizzazione di Access o di qualsivoglia altro 
strumento dovresti ignorarla: quando pretendi un ordinamento preciso sui 
dati, inserisci una clausola ORDER BY nella query SQL per garantirlo.
