Newsgroup: it.comp.lang.visual-basic
Titolo: ADO e interfaccia utente

Ciao a tutti
dopo un po' che sto usando ADO mi è venuta fuori una bella considerazione:
è veramente eccezzionale, se volessi creare un programma senza interfaccia
utente, che si inventa lui i dati, se li modifica, elimina e aggiunge, di
sicuro mi verrà utile.
il problema è che i miei clienti (non so i vostri) si sono incaponiti a
voler anche interagire con i dati: ad esempio vogliono creare una fattura
nuova, e non contenti si ostinano a voler inserire diverse righe di fattura
(che pretenzionsi).
con il vecchio DAO (dinosauri, sucuramente il nuovo ADO è più efficiente e
pratico da implementare) era a dir poco un gioco da ragazzi fare queste cose
inutili come le interfacce utenti.
devo veramente credere che per aggiornare una tabella in cui ci siano dei
record correlati su altre tabelle attraverso codici in integrità
Referenziale, mi devo scrivere decine di righe di codice solo perche un
recordset con più tabelle correlate diventa cazzosamente readonly?
dove sto sbagliando nell'approccio a questo cacchio di tecnologia?
P.S. ADO l'ho utilizzato efficacemente per creare siti con ASP e sono stato
soddisfatto del sistema, perche non riesco ad utilizzarlo in maniera pulita
anche per VB con interfaccia utente?
Fabio


[snip]
???
Facci capire un po come scrivi codice Ado, va...
???
ciao
ugo


porto un solo caso tra tutti quelli che non mi convincono
diciamo che ho due tabelle legate da una relazione uno a molti:
Tabella Animali
-----IdAnimale    Long
-----Nome    VarChar
-----RifRazze    Long
Tabella Razze
-----IdRazza    Long
-----Nome    VarChar
legate da una relazione uno a molti  Animali.RifRazze----->Razze.IdRazza
a questo punto creo un command con l'istruzione:
SELECT Animali.*, Razze.Nome
FROM Animali LEFT JOIN Razze ON Animal.RifRazze = Razze.IdRazza
il recordset restituito è perfetto in lettura, ma al contrario di cio che fa
access non posso eliminare i record.
(idem con patate se il command punta ad una query definita direttamente sul
Database Access)
a questo punto ho trovato diverse soluzioni ma tutte poco eleganti (e voi
sapete meglio di me che quando si programma in modo sporco il codice diventa
impossibile da manutenere) come ad esempio inserire nelle maschere controlli
legati alla vista per ottenere la visualizzazione che voglio ed altri legati
alle singole tabelle per eliminare/aggiungere/modificare i record. per
funzionare funziona ma ho dovuto scrivere tonellate di codice per mantenere
allineati i recordset con la vista e di conseguenza con i controlli legati,
nonchè per cercare quali possibili errori possono venirsi a verificare
ecc...
l'esempio è volutamente banale per far si che il problema diventi chiaro ma
voi sapete benissimo che i problemi non sono mai così semplici, cosa mi
toccherà fare allora quando dovro preparare maschere su Viste che
coinvolgono 4-5-6- ecc.. tabelle? non posso perdere una settimana su una
maschera di gestione di questo tipo per ottenere poi un prodotto che se mi
dovessero chiedere di aggiungere un campo ad una tabella mi conviene
scappare in perù a coltivare i peperoni piuttosto che effettuare
l'aggiornamento.
alla fine della corsa mi ritrovo a pensare seriamente di tenere ADO solo per
la programmazione ASP e tornare a DAO per le applicazioni Desktop.

 legate da una relazione uno a molti  Animali.RifRazze----->Razze.IdRazza
scusate la relazione non č questa ma : Razze.IdRazza------>Animali.RifRazze
con il lato Molti sulla tabella Animali
ciao


Fai come preferisci.
Ado č sicuramente enormemente piů flessibile, scalabile e riutilizzabile,
nonchč piů efficiente nella gestione client-server di Dao.
Tuttavia occorre senz'altro una maggiore conoscenza del funzionamento dei
database, delle differenze intrinseche tra i diversi tipi di provider dati
e, in ultrima analisi, anche dei diversi dialetti Sql.
In altre parole, occorre conoscerlo bene. Studiatelo un po e te lo farai
amico... :-)
ciao
ugo

 Sicuro di aver impostato il recordset come adopendynamic,
adlockoptimistic?
Si
Ho provato anche a realizzare un db di test per vedere di non aver
trascurato qualcosa, vi ho messo due tabelline semplici semplici:
tabella Uno
Id    Long (chiave)
TestoUno varchar
tabella Molti
Id    Long (chiave)
TestoMolti    Varchar
RifUno    Long
la sua bella relazione molti.rif Uno---->Uno.id
una vista:
SELECT molti.*, uno.testoUno AS Testouno
FROM molti LEFT OUTER JOIN uno ON molti.Rif = 
uno.id
adopendynamic, adlokoptimistic
cursore Client Side
non posso eliminare (per quello che so di SQL mi aspetterei che in questa
vista si possano eliminare i record della tabella molti)
in compenso ho verificato che non è vero che non mi lascia aggiungere,
questo lo posso fare e posso anche modificare, (chiaramente solo i campi
testomolti e rifuno)
PS non è che tutto questo possa essere un problema risolvibile con un
servicePack di VB??
sto usando ADO 2.5
ma VB è ancora nella prima release (sto scaricando SP5 ma mi ci mette un bel
po di tempo)
Grazie del tempo che mi state dedicando

Ho appena fatto una prova:
ho trasferito il db su Sql7
ancora quando elimino mi da un errore, ma in questo caso il record
nonostante l'errore viene eliminato. speravo di chiarirmi un po le idee con
questa prova invece sono sempre più confuso.


Aggiungo qualcosina per chiarire meglio quello che ti vuole dire Ugo...
Ado non è pensato per funzionare access-like, ma per essere scalabile su
dbms seri.
Purtroppo Access ci ha abituato molto male, nel senso che permette di fare
cose molto sporche che poi provvede a gestire lui in modo trasparente. Caso
classico quello che indichi tu di inserimento o cancellazione attraverso un
join.
Normalmente in un dbms classico, Sql server, Oracle, si usano istruzioni
diversi per le varie operazioni, per ottimizzare le prestazioni e perchè il
loro sql è molto più rigido. Access, dietro le quinte, gestisce lui l'insert
nella tabella giusta e gli aggiornamenti dei vari recordset.
questo è molto comodo, ma ha un prezzo in termini di prestazioni che diventa
rapidamente troppo caro da pagare anche per applicazioni non molto grandi.
Infatti La Ms ha creato con Access i progetti Adp (che bypassano Jet e
lavorano direttamente con Ado), che con Sql server hanno un aumento di
prestazioni sorprendente. Orbene, in un progetto adp, se crei una maschera
basata su un join, devi indicare ad Access la tabella principale, in modo
che lui possa costruire le appropriate stringhe di insert, delete ed update
su di essa.
Questo credo dimostri il punto, che poi in sintesi è: per lavorare con Ado
bisogna modificare il modo di lavorare, e pensare di più in termini di dbms
e sql.
In sintesi alcuni suggerimenti, molto personali:
1) Via i controlli data! Carica i controlli a mano con una select e
2) gestisci update, insert e delete con strighe sql. E' più faticoso ma hai
il controllo completo, e le prestazioni aumentano di molto.
Oppure in alternativa:
1) Lavora sempre sulle tabelle e per le foreign key usa dei combo box o list
box, o
2) al limite delle select tipo "Select DESCR FROM tabellarelazionata WHERE
Id=mio campo", anche se questo è lo scimmiottamento della seek.
Ricorda che i comandi INSERT, UPDATE, e DELETE in ambienti transazionali
sono enormemente più performanti di addnew, ecc
Infine, vorrei notare che dopo essermi rassegnato all'uso più spinto di Sql
ho scoperto che lavorando in modo più sofisticato con Sql si ottiene codice
più stringato ed enormemente più performante.
Per non dire più scalabile, perchè poichè è eseguito tutto sul server, ed
ottimizzato dal dbms, è facile da migliorare aumentando la potenza del
server.
Hth
Ciao
Alfonso

Così stando le cose davvero non vedo perchè non ti permetta di cancellare
dal lato molti.
Come crei la connection e il recordset?
ciao
ugo

 SOTTO :((((((
Farai felice Pal e tanti altri... :-)
[snip]
Se ti dico che anche stavolta hai riassunto splendidamente i termini
generali del problema che fai... :-P
ciao
ugo

Grazie, Grazie, Grazie
ero convinto sbagliando che utilizzando i controlli potessi avere
piattaforme più affidabili per l'inserimento e la modifica dei dati (nonche
la cancellazione), voi mi dite che usando dirattamente i command con le
istruzioni SQL il codice risulta più potente ed elegante, visto che mi trovo
decisamente più a mio agio in questo modo (programmando Asp con db SQL 7 era
sicuramente funzionale) da oggi proverò a progammare Vb utilizzando cio che
ho imparato in Asp.
effettivamente se penso al fatto che ADO è progettato principalmente per i
DBMS mi viene in mente che questo sistema dovrebbe essere anche il più
congruo.
P.S. voi sconsigliate anche l'utilizzo del DataEnvironment?
ri-grazie
spero di poter un giorno essere utile a voi come voi lo siete stati per me.


Sì.
:-)
ciao
ugo