Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Beccare un record senza bookmark

Supponiamo di avere un recordset fatto di "n" records. Non so bene quale sia
la logica (il significato) dei campi, però ne conosco il nome, il tipo e il
contenuto. Espongo i records in una griglia. L'operatore clicca su una riga
della griglia e poi vuole editare o eliminare quello specifico record.
Certo si potrebbe, conoscendo (e si conosce) il nome e il contenuto di ogni
campo del record selezionato, fare una query che dice "Select from
Tabella_originale Where Campo1=valore_campo1 And Campo2=valore_campo2 ...",
ma è piuttosto laborioso: occorre conoscere la tabella di origine (e se sono
più tabelle?), il tipo di ogni campo per adeguarne la sintassi nella sezione
Where e poi, non per ultimo e per rimettere la testa al toro, ... potrebbero
esserci records identici in tutti i loro campi (strano, vero, ma possibile).
Quindi escludiamo anche vari metodi (che, alla fine, hanno lo stesso scopo)
come Filter, Find..., e compagnia bella.
La domanda è: Esiste un modo, senza salvare in un vettore in memoria (con
quello che vuol dire in termini di occupazione) i bookmarks (sempre che ci
siano, ma questo lo posso dare per certo, nel senso che se non ci sono non
consento nemmeno quella funzionalità) di tutti i records per individuare con
certezza uno specifico record senza conoscerne la struttura logica (non so
se c'è e qual è il campo ID, per esempio), ma conoscendo solo ed
esclusivamente il nome, il tipo e il valore dei campi? Grazie.

 della griglia e poi vuole editare o eliminare quello specifico record.
Capisco il problema.
Nel caso che il recordset sia popolato con un join di più tabelle, credo che
il tuo  problema non abbia molto senso (in quale tabella vuoi eliminare? E
come sapere qual'è?)
Se invece il tuo recordset nasce da una sola tabella, puoi utilizzare il
Delete di Ado.
Cliccando sulla griglia, ti viene passato il numero di riga interno alla
griglia. Esso corrisponde alla posizione del record nel recordset. A questo
punto, non devi neppure eseguire il move, in quanto il puntatore del
recordset dovrebbe essersi già spostato (nel momento del click), sul record
voluto. Teoricamente basta fare Delete e UpdateBatch. Se invece (non ricordo
bene...), il record corrente non si è spostato col click, basta eseguire un
Move sul numero di record ottenuto, e fare Delete e UpdateBatch.
Tu comunque avevi già presentato una possibile soluzione, ossia quella,
conoscendo nome, tipo e valore di ogni campo
(Recordset.Fields.Item(indice).Name, Recordset.Fields.Item(indice).Type,
Recordset.Fields.Item(indice).Value), di creare una stringa Sql con un
Delete Where ....
Il caso di due record identici, del tutto ammissibile, può essere risolto
eseguendo il Delete solamente di un record (se sono identici, cosa cambia
cancellandone uno o l'altro? Del resto oramai quasi nessun DB è
posizionale).
Resta il caso in cui il recordset è creato con una query in cui un campo
viene rinominato. Credo che la prima soluzione sia la migliore.
Ciao
Alberto

 griglia. Esso corrisponde alla posizione del record nel recordset...
No (lo so che mi/vi complico la vita), se la griglia č Unbound e se
l'operatore ha fatto ordinamenti e/o selezioni....
Grazie comunque.

 l'operatore ha fatto ordinamenti e/o selezioni....
Giusto.
Allora resta valido il discorso del creare la condizione where sfruttando
l'elenco dei campi del record.
Oh, insomma... In qualche modo sto cazzo di record bisogna pure
identificarlo.
Non hai l'ID, ci sono record identici, la griglia č unbound e le righe sono
ordinate in modo diverso dall'origine dati...
Non vedo altro che un Delete Where
Ciao
Alberto

 posizionale).
Questa condizione NON SI DEVE MAI verificare, in quanto così facendo vai
contro la prima forma normale! (per maggiori info
http://databases.about.com/library/weekly/aa080501a.htm
 ).
In un database relazionale ogni tabella DEVE avere una PK.
Se ad es. in SQL Server crei una tabella senza PK ed inserisci 2 records
completamente uguali.... prova a fare una DELETE e guarda cosa succede...
Es:
CREATE TABLE dbo.Demo (
    Nome varchar(50),
    Cognome varchar(50)
)
GO
INSERT INTO dbo.Demo
VALUES ('Lorenzo', 'Benaglia')
INSERT INTO dbo.Demo
VALUES ('Lorenzo', 'Benaglia')
INSERT INTO dbo.Demo
VALUES ('Mario', 'Rossi')
DELETE dbo.Demo
WHERE Nome = 'Lorenzo' AND Cognome = 'Benaglia'
SQL Server non saprà discriminare tra i due records e quindi li eliminerà
entrambi!
Se provi a selezionare un record duplicato da Enterprise Manager e cerchi di
eliminarlo ti verrà visualizzato il messaggio d'errore: "Key column
information is insufficient or incorrect. Too many rows were affected by
update."
Per concludere: bisogna ricordarsi di creare SEMPRE in OGNI tabella una PK,
basandosi su un campo significativo univoco(Codice fiscale, nr. Patente, nr.
Carta di Identità, ecc..) o in sua assenza creare un campo IDENTITY o se è
il caso GUID.
Ciao!
--
Lorenzo Benaglia
UGIdotNET - 
http://www.ugidotnet.org

 contro la prima forma normale!
Lorenzo, hai perfettamente ragione, ma io, giusto per farmi capire, sto
cercando di fare un "mio" Data Manager e non posso quindi trattare i dati
(unbound e messi in una listview) in modo "logico", perchč č l'operatore che
li sceglie, seleziona, ordina, etc. In poche parole, io non ne conosco il
significato logico, ma solo la grezza struttura fisica.
Attualmente consento variazioni _solo_ se il recset ammette i bookmarks (che
mi archivio in memoria) e quindi mi basta fare rs.bookmark=valore (dove
valore proviene dal mio vettore che abbina le righe esposte con quelle del
recset) e accedo direttamente al record interessato.
La mia domanda era per poter estendere le variazioni anche a recset senza
bookmarks.
Grazie comunque.

 il caso GUID.
Qualche maiuscola in meno era più gradita.
Alberto

 Qualche maiuscola in meno era più gradita.
Hey, non era mia intenzione quella di offendere nessuno!!
Se l'ho fatto, ti chiedo scusa.


 Se l'ho fatto, ti chiedo scusa.
No problem.
Ero molto incazzoso, qualche ora fa.
Ciao
Alberto

 Ero molto incazzoso, qualche ora fa.
Bene, sono contento di non aver creato un "incidente diplomatico" :-)


 6.5 :-))
In realtà, ogni motore relazionale può essere utilizzato in modalità
non-relazionale, o quantomeno con relazioni e integrità referenziale ridotte
al minimo.
Avendo iniziato la mia carriera nell'ambito dell'OLAP ante-litteram, con i
primi patetici tentativi di IBM su OS/2 con "Visualizer", e avendo di fatto
realizzato alcune forme di data-warehouse strutturate su DB2 (AS/400) come
fonte dati, Fox-Pro su Win3.x come supporto dei cubi, e Excel 5 come client
Olap, mi ritrovo oggi a dover adeguare la mia forma mentale (oramai
spregiudicatamente votata al multidimensionale), alla disponibilità di
strumenti sempre più relazionali.
Tuttavia, ho notato che l'approccio multidimensionale sta tornando di moda.
La stessa MS, con Sql2000, ha finalmente creato un vero server per cubi.
Operando con SAP R/3, moltissime strutture, soprattutto nel modulo FI-CO
:-), presentavano la ridondanza di alcuni elementi, che visti in ottica
relazionale sarebbero stati interpretati come vere eresie.
Considerando che gli svantaggi del multidimensionale erano sostanzialmente
due:
1) La ridondanza. Alcuni valori possono essere ripetuti su più record.
Occorre gestire bene l'aggiornamento, per evitare incongruenze, per cui
avanti con le Transaction
2) Lo spazio. Un tempo, ogni GB voleva dire decine di milioni. Le strutture
relazionali consentivano di alleggerire tantissimo lo spazio occupato.
Oggi, il punto 2 è assolutamente superato, a chi importa se un DB occupa 1GB
o 2GB?
D'altro canto, la velocità di esecuzione delle query sul multidimensionale
può essere anche parecchi ordini di grandezza migliore del relazionale.
E non è influenzata più di tanto dall'ottimizzazione della query stessa (con
un ER puro, l'ottimizzatore di query deve valutare tutti i criteri per
decidere l'ordine di selezione all'interno dei vari join).
Comunque, la cultura imperante, soprattutto in conseguenza dei corsi
universitari dove il modello ER viene insegnato come "il verbo", è quella di
partire dall'analisi e di disegnare il DB con rigorosa struttura
relazionale.
In alcuni casi, qualcuno si lancia in strutture multidimensionali, ma
relegando la cosa a tabelle marginali, generalmente destinate all'analisi
dei dati (appunto, Dss, Olap e simili), per sfruttare la velocità di
esecuzione e la facilità di accesso intuitivo.
Il mio approccio, pur avendo subito anche io il Bonfa (chi ha orecchie per
intendere, intenda), è esattamente l'opposto.
Dopo l'analisi, mi avventuro nella strutturazione multidimensionale, salvo
ricorrere al relazionale quando mi rendo conto che, dovendo sfruttare motori
relazionali, lo spreco di spazio o la ridondanza diventano non tollerabili.
Va beh, adesso che Leone di Lernia col suo 'Macarena' mi ha svegliato da
questa trance da allucinogeni, me ne torno al lavoro.....
Ciao
Alberto