Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Mysql con VB6, script sql

Salve a tutti
Ho un problema che non sono riuscito a
risolvere utilizzando ricerca google nei gruppi
ne con la documentazione in linea di VB6.
Stò provando a scrivendo un software che
lavora in rete e utilizza:
-VB6
-mysql come server di db
-oledb(MyOLEDB3) per mysql trovato in rete
Ho il problema di prelevare il contenuto di alcuni
record modificarli(in VB) e riscriverli.
Mentre li modifico non devono essere modificati da altri
utenti del db.
L'oledb utilizzato non supporta i lock.
Ho implementato una tabella dei lock in cui vado a scrivere
la tabella e il record in modifica. Cosi' quando si deve
operare una modifica, come in precedenza, si esegue una query
per vedere che nessuno è in modifica sul record. Se il record
non è lock si inserisce la riga indicando il record e la tabella
in modifica.
Il problema è che come faccio a garantire che nessuno locka il 
record tra quando non trovo il lock sulla tabella e quando scrivo il lock??
Potrei usare il comando "lock tables lock_tabel write", ma quando metto il
lock:
  cmd.CommandText ="LOCK tables lock_tabel WRITE"
  Set rs = cmd.Execute()
per mysql il comando precedente rappresenta un solo thread 
e il lock è perso quando questo finisce.
Comunque, come faccio a eseguire più istruzioni sql in una sola volta(1
thread)??
Dalla documentazione di vb ho visto che si utilizzano le stored procedure,
ma con mysql la procedura esposta non si può eseguire.
Molto probabilmente con mysql non sono supportate le stored procedure.
Con google non ho trovato soluzione.
Secondo voi operando su una rete a 100 Mb con la tabella dei lock, che sarà
si curamente non molto grande, il software sarà lento se fa qualche query 
prima delle modifiche??
Grazie 1000 per l'attenzione
Valdes
 
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 lock??
già...!
Dopo aver depositato il tuo lock (immagino proprio perchè non hai trovato
lock di altri) ripeti, una sola volta la verifica (rinfrescando i dati),
ovvero se il tuo lock c'è e non ce ne sono di altri allora puoi procedere
perchè anche gli altri troveranno la stessa condizione (e quindi staranno
fermi). Viceversa togli il tuo lock e riprova come se fosse la prima volta.

Lupo ha scritto:



Grazie Lupo per la risposta.
Alla fine della ho deciso di
implementare una soluzione in cui sfrutto
l'orario di inserimento del lock, una tabella con i seguenti campi:
tabella con record da lock(are) | id record da lock | utente | timestamp
Il campo di timestamp è riempito con
il comando current_timestamp()(func. mysql). L'algoritmo funziona in
questo modo:
- inserisco il lock del record con il timestamp
- eseguo una query di tutti i record con la stessa tabella e l'id del
record da lock(are)
- se ce ne sono più di uno confronto i timestamp , che mi permette
   di capire se sono stato il primo a dare il lock o meno.
in questo modo evito di dare il refresh.
- con il timestamp posso anche sfruttare una coda di eventuali 
   aggiornamenti(automatici e non manuali), ad esempio scalare un 
   numero di prodotti da una quantità di prodotti. Logicamente, 
   effettuando dei refresh per vedere quando l'utente(proc. autom.) che a 
   operato il lock prima di me ha terminato.
** Il mio unico dubbio è se ci potrebbero essere due scritture 
nello stesso secondo(risoluzione del timestamp al secondo),
essendo il timestamp del tipo:
1/03/2004 20.10.03
Nel caso dovrei prevedere il caso di due timestamp uguali nel
confronto dei timestamp, ovvero citandoti:
"togli il tuo lock e riprova come se fosse la prima volta".
Se sufficiente la risoluzione al secondo mi informerò.
--
Indirizzo email togliere circa_


 Se sufficiente la risoluzione al secondo mi informerò.
Appunto...
Io proporrei invece questa sequenza:
1-Determini una sigla (stringa) che identifica precisamente (anche
convenzionalmente, per esempio il nome della tabella e la chiave univoca che
ne identifica un record, per esempio il codice univoco di un cliente, chiaro
che tutti devono adottare lo stesso metodo, altrimenti "non ci si
capisce"...) la zona (record, serie di record, tabella, intero database,
etc.)
2-Vedi se nella tabella dei lock c'è un lock (non della tua postazione!) che
comprende (o è compreso) la zona che stai bloccando. Se sì, cicli e ripeti
questa verifica (punto 2), viceversa depositi il tuo lock e procedi al punto
3.
3-Siccome altri potrebbero aver depositato il proprio lock fra la tua
verifica (inizio punto 2) e il tuo deposito (fine punto 2), riverifichi,
ovvero ripeti il punto 2, con la uletriore verifica (per estrema sicurezza)
che il tuo lock ci sia. Se la verifica è positiva (ci sono lock di altri per
la stessa zona), cancelli il tuo lock (è importantissimo) e ripeti dal punto
2. Se la verifica è negativa (non ci sono altri lock) allora puoi essere
certo che altri troveranno il tuo e quindi non depositeranno (o toglieranno)
il loro lock e procedere tranquillamente, per un secondo o (sconsigliabile,
ovviamente) un'ora. Alla fine togli il tuo lock. Attenzione: potrebbe
(eccezionalmente) verificarsi una situazione "ciclica", ovvero i lock si
"rincorrono" e, per il gioco dei tempi, non si risolvono mai a favore
dell'uno o dell'altro. Prevederei semplicemente un timeout (per esempio, 30
secondi). Se la cosa non si sblocca entro tale tempo, generi un errore o
chiedi all'operatore se ripetere per un'altra sessione di tentativi.
Ovviamente devi prevedere (io lo faccio anche quando una postazione,
univocamente identificata, entra in procedura oppure esce) un'utility che
consenta di togliere i lock di una (o più, anche tutte) postazione. Se una
postazione, infatti, si impianta, rischia di lasciare i suoi lock nella
tabella e tutto si fermerebbe...

 Indirizzo email togliere circa_
Non ci posso credere!!! ;-)

[Lupo] scrisse:
(snip)
cutto tutto, e lancio una provocazione, spero fruttifera...
se il problema è quello di prelevare un dato, modificarlo e riscriverlo su
un database, e verificare se nel frattempo qualcuno lo ha già modificato,
non è più agile andare a verificare il timestamp del record?
sostanzialmente: prelevo il record, completo di timestamp, lo modifico e
quando vado a scrivere le modifiche verifico preventivamente che il
timestamp sia ancora quello, nel caso non lo sia avviso l'operatore che
qualcuno gli ha modificato i dati sotto il naso e lo invito a caricarsi la
versione aggiornata dei dati.
direi che rispetto alla gestione dei blocchi ho un aspetto negativo: quando
l'utente aggiorna un record non è sicuro del fatto che le sue modifiche
saranno accettate, ma d'altro canto semplifica di molto la codifica e evita
radicalmente il problema dei blocchi permanenti (o di quello che è andato a
bere il caffè tenendo aperto un record)
-- 
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

 di quello che è andato a bere il caffè tenendo aperto un record)
Personalmente blocco solo quando vi saranno solo elaborazioni macchina, non
umane, per cui il blocco è limitato alle velocità hardware/software, non
operative.

 tabella e tutto si fermerebbe...
Ho implementato la rimozione dei lock dello specifico operatore sia
quando entra nella procedura di competizione del lock dei record
sia quando esce.
Il problema è che ho due tipi di aggiornamenti:
-1-modifiche di record manuali da parte di un operatore
-2-modifiche di record automatiche
in generale potrei utilizzare un campo con un flag che segnala se è una
modifica manuale o automatica.
In modo tale che l'utility(sul server) controlla ogni tot di tempo 
(es.5 min) i record nella tabella dei lock.
Per il caso -2- se tra due interrogazioni successive un record  
di aggiornamento automatico è ancora lock e contiene lo stesso timestamp
precedente, viene rimosso.
Comunque, è un tentativo di gestione di un magazzino(che non esiste) con
vendita al dettaglio quindi le quantità di prodotto sugli scaffali
le faccio aggiornare, se durante la vendita trova diverse volte il record
lock.
Penso che l'importante è registrare le uscite dei prodotti.
Non si può bloccare una vendita, poi le anomalie le registrerò.
Per il caso -1-, al login e al logout di ogni operatore si controlla se
non ci
sono "lock pendenti" di operatori non loggati(non prevedo tanti operatori).
Inoltre, ho implementato che quando un'operatore entra in modifica 
su un record lockato(modifica non concessa), da altro operatore,
si segnali l'operatore che l'ha lock. 
Nel caso di anomalie, implementerò che un particolare operatore
(amministratore)può rimuovere i lock degli operatori tramite una procedura.
Spero di non essermi dilungato troppo...
Saluti
--
senza tanta fantasia...


 Non si può bloccare una vendita, poi le anomalie le registrerò.
Una cosa importante che non ho detto: fra il mio "blocco, lavoro, sblocco"
quella fase "lavoro" è sempre ed esclusivamente tempo macchina, ovvero non
presume mai l'intervento dell'operatore, per cui escludo che (tipico
esempio) un operatore blocchi un articolo, se ne va a bere il caffè e magari
riceve una chiamata urgente per cui deve uscire e non sblocca più...

 riceve una chiamata urgente per cui deve uscire e non sblocca più...
Le modifiche di una scheda di prodotto, cliente o fornitore le ho
implementate in
modo che quando un operatore la modifica, nessun altro operatore la può
modificare.
Ad un operatore che entra in modifica, su una scheda in modifica da altro
operatore, viene segnalato che la scheda è lockata e quale operatore
la stà modificando.
Non preferisco una situazione in cui due operatori in modifica sulla stessa
scheda, poi quando salvano rimane la modifica dell'ultimo che ha salvato.
Differenziare, perchè il caso di modifiche precedenti è diverso rispetto
al caso in cui si deve sottrarre una quantità di prodotto in seguito ad
una vendita. In questo caso non si deve aspettare che l'operatore
termini di fare le modifiche manuali.
Saluti
--


 termini di fare le modifiche manuali.
Non capisco, forse perchè, come dicevo, io non blocco mai se prevedo
l'intervento dell'operatore, ma solo prima di tempi di lavoro macchina.

 Non ci posso credere!!! ;-)
LOL
-- 
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
Statuto: 
http://www.it-lang-vb.net/docs/Statuto.txt
UGIdotNET - 
http://www.ugidotnet.org

 LOL
Scusate, ma non mi è chiaro... cosa c'è di strano,
saro' de' coccio, ma non capisco.


 l'intervento dell'operatore, ma solo prima di tempi di lavoro macchina.
Ok! mi hai chiarito abbastanza le idee.
Comunque io stò usando ADO data (mi sembra che non è molto amato), che
permette di scorrere i record.
Com'è noto quando si tento di salvare un record che qualcuno ha modificato,
dopo che il recordset è stato caricato, da problemi.
Quindi, la mia necessità di bloccare il recordset per tutto il tempo
che un operatore esegue le modifiche era nata da questo.
Saluti


 saro' de' coccio, ma non capisco.
Niente, è che qualcuno (giusto Lokar) mi ha consigliato di non pubblicare
nel quoting l'indirizzo mail di chi ha scritto il post a cui rispondo,
allora io, tramite QuoteFix, ho modificato anteponendo un "circa_".
Tu, nel tuo secondo post in questo topic, hai firmato con "Indirizzo email
togliere circa_" ;-)