Newsgroup: it.comp.lang.visual-basic
Titolo: Record Correlati & Cancellazione

Private Sub cmdDelete_Click()
  With DBPreventivo.Recordset
    mess$ = "Vuoi DAVVERO CANCELLARE QUESTO PREVENTIVO ?"
    risposta$ = MsgBox(mess$, vbOKCancel, "Elimina Preventivo")
    If risposta$ = vbOK Then
       .Delete
       .MoveNext
       If .EOF Then .MoveLast
    End If
   End With
End Sub
Guardate questa procedura , è corretta , ma quando provo a cancellare un
record ecco cosa mi appare  (se ci sono record correlati) :
The record cannot be deleted because table 'articoli_prev' includes related
records
Se non ci sono record correlati (dopo avere cancellato il record) :
Runtimes error 3021  no current record
Ed ecco la riga di codice che in questo caso provoca l'errore 3021
DBarticoli.RecordSource = "SELECT * FROM [righepre] WHERE [id_preventivo]="
& DBPreventivo.Recordset![id_preventivo]
DBarticoli.Refresh
Come sistemo questo pasticcio ?

 DBarticoli.Refresh
se elimini la scheda con quel preventivo, ed era l'unica, la query per forza
dopo ti restituisce un rs vuoto. o lasci il msgbox o *dopo l'eliminazione*
imposti il rs in modo diverso. select *, o come vuoi.
ciao, a.

 chiamerebbero cosi').
uffa ! consentirai che come al solito -- specie in un campo volubile e
opinabile come l'informatica -- le opinioni possano confrontarsi prima di
passare alle valutazioni ? insisto, il c *non* e' *meglio* di vb tout court,
e' meglio *in date condizioni*, alcune strettamente informatiche altre no.
seno' siamo al tifo inter - tifi milan.
il gestore di un grosso ced mi sosteneva  qualche giorno fa che lo script
dei mainframe ibm non e' peggio di word, solo diverso. avra' ragione lui,
contro circa 2-3-400 mln di utenti windows ? -- non lo so, e francamente non
me ne frega una minchia. io uso word, e ci ho fatto un libro (parlo di
impaginazione, correzione bozze, ecc., fino a mandare una ciano in
tipografia) in una settimana. col suo script per fare un libro ci ho messo
sei mesi... ed e' rimasta una qta' di errori che ancora sprofondo.
tralasciando ovviamente la qualita' dei caratteri, spaziatura e rientri
delle note, e tanti altri dettagli che sono poi quelli che distinguono
(tip.) un bel libro da uno brutto. ma se a lui e' sufficiente script, buon
per lui.
dunque, a delimitare la mia asserzione sulle relazioni nei db c'era una
postilla: "comporta grossi rischi. sol che lo si sappia...".
per abitudine, preferisco il rischio lasciare qualche orfano e pensare fin
dall'inizio a procedure di controllo. in clipper usavo spesso "seek ... if
eof()" --( appunto con la struttura:
    get pippo
    seek pippo
    if eof()
        /* dimmi qualcosa
        torna al get */
    endi
    // se arriva qui pippo c'e' per forza
)-- che e' esattamente questo. qui mi sono convertito all' "if nomatch",
dopo che vb ha poco apprezzato la mia abitudine. in cobol -- il corso di 6
mesi era tutto sui db -- nessuno me le ha nemmeno mai nominate, le
relazioni...
che le relazioni siano la base di un db <g> relazionale e' indubbio.
*molto* meno indubbio e' *cosa siano* e *chi debba stabilirle*.
tirare una linea in 4th dimension o in access equivale esattamente a dirsi
"questo e' il legame fra le due tabelle; cosa succede se elimino l'1 in una
relazione 1-n?".
se un mio clipper dal 91 -- inizialmente (motivi esterni) con una trentina
di tabelle e una settantina di indici (poi grazie al cielo ho avuto
l'occasione di snellire la struttura) -- fino ad oggi non ha perso un colpo
pur in mano a utenti del tutto inesperti, vuol dire che al problema ci penso
e cerco di risolverlo, o quantomeno di gestirlo.
es.: qualcuno due giorni fa mi diceva: con resumenext risolvi tutto. non e'
assolutamente vero: prova a usarlo con un db che maneggi soldi e ti accorgi
che meno ti fidi di *tutto quello che non e' tuo* meglio e'. almeno se
qualcosa non va sai con chi prendertela...
invece, appunto ai tempi di clipper, vedevo tanti che usavano le relazioni
tipo join e perdevano pezzi per strada, indici corrotti (erano gli anni di
tangentopoli, d'altronde :)... il clipper di cui sopra sostituiva appunto un
db4 fatto da una sw house come tante e che moriva regolarmente. anche
perche' chi si fida ciecamente delle relazioni temo tenda a sottovalutare i
controlli...
access sara' meglio, non discuto, ma:
0. senz'altro conosco troppo poco i db e il loro mondo, sql e ado per tutti.
cmq access a me serve per scrivere le tabelle e per fare i seek e i pack.
esattamente quello per cui mi serviva dbase. per il resto, se mi dai la
possibilita' di tabelle in txt, preferirei. (non eri tu che ventilavi di
scriverci un db xml?). le tabelle dbf mi piacevano molto perche' c'era un
header e poi i dati. capito il primo, volendo leggevi il file con un editor.
in access col cavolo che recuperi archivi i cui primi record sono andati
persi per un buco nel floppy.
1. la storia di relazioni e indici corrotti: per capire che il fuoco brucia
cerco di far si' che mi basti l'esperienza -- leggi: le scottature --
altrui. anche se questo mi richiedera' maggior tempo. d'altronde non sono un
pro, e finche' posso cerco di permettermelo. con altri db e in altre
situazioni (team p.e.), dispostissimo a ripensarci se la linea di
maggioranza e' un'altra.
2. devo fidarmi ciecamente di access e sqlserver, sulla base di quello che
vedo capita a windows, word, e altri prodotti della stessa provenienza ?
anche excel (nella mia esperienza, il miglior sw ms in assoluto, quello su
cui continuo a pensare mettano, volontariamente o no <g>, i programmatori
migliori) che -- spesso ma non sempre (il che e' anche peggio) -- se
seleziono una colonna e imposto sfondo o carattere da' errore irreversibile
? se su str**te cosi' ci sono questi risvolti, su cose piu' serie ?
3. anche nel caso, se poi cambio db ? chi mi garantisce che le relazioni
(cioe', soprattutto, la loro gestione) impostate in access le converto
tranquillamente in oracle, informix, db2 ? certo, tutto si converte in
tutto. o quasi: dopo avere convertito dei dbf in mdb mi sono reso conto che
la faccenda non era affatto reversibile. le mie, di relazioni, dovrei essere
in grado di capirle anche dopo avere convertito le sole tabelle.
conclusione mia (non vorrei innescare un tormentone, quindi anche se non la
condividi p.f. concedimela e pax): le relazioni pertengono alla sfera
dell'intelletto, non dell'informatica. poi ognuno se le implementa -- non
solo in informatica -- come crede, puo' e riesce.
ciao, a.