Newsgroup: it.comp.appl.access
Titolo: Problema db FE-BE e sincronizzazione delle query

Un saluto a tutti.
 
Chiedo scusa in anticipo sia per la lunghezza, sia per la complessità del post.
 
Sto riscontrando uno strano problema con un'applicazione multiutente suddivisa in FE e BE.
 
- Gli utenti accedono a una form(frm1 - modale - scollegata) la quale
  integra una subform;
 
- quest'ultima viene popolata dalle occorrenze prodotte da uno statement
  sql("SELECT * FROM tbl1 WHERE AnnoDiCompetenza=year(Now) AND ...etc.") creato
  da un'apposita funzione(l'output 'tipo string' della funzione
  viene immesso nel recordsource della detta subform).
 
  Come avrete notato, le occorrenze selezionate rappresentano un 
  subset dei record della tbl1(lo statement seleziona i record del 
  corrente anno di competenza) 
 
- dalla frm1 l'utente richiama una form di dataentry(frm2) da dove
  può inserire/modificare i record della tabella legata al 
  recordsource della subform.
 
- Ad ogni corretto inserimento/modifica:
  1) frm2 viene chiusa in automatico;
  2) il focus ripassa alla frm1;
  3) viene rinvocata la funzione di popolamento della subform
 
 Fin qui il tutto funziona egregiamente; se l'utente U1 inserisce un
 nuovo record, un secondo utente (U2 - altro FE) registra quanto segue:
 a) in caso di modifica, dopo l'intervallo di default di sincronizzazione,
    il record della subform viene aggiornato con le modifiche;
 b) in caso di inserimento, la subform viene aggiornata con la nuova 
    occorrenza su azione diretta dell'utente: tramite un button(btn1) che
    trigga la funzione di popolamento dela subform.
 
Veniamo al problema.
 
La frm1 contiene anche un'altra funzione, invocabile tramite un button(btn2), la quale, in certe circostanze, comporta l'aggiornamento di più record della tabella legata alla subform(alcuni record con l'anno di competenza precedente vengono attualizzati - e.g AnnoDiCompetenza=2011 viene modificato in  AnnoDiCompetenza=2012).
 
Ecco, in questo caso,successivamente alla pressione del btn1, la vista della subform dell'U2 non cambia.
 
Se però l'U2 chiude la form e la riapre, Hocus Pocus: le nuove occorrenze appaiono d'incanto!
 
Per ulteriore verifica dell'inguacchio, ho anche provato a inserire un bottone(btn3) che richiama una form popolata con i record di una query correlata a un'altra tabella(tbl2).
 
Se l'U1 modifica i record della tbl2, l'U2 premendo il btn3 non vede le modifiche(permane la vista precedente alle modifiche).
L'u1, invece, premendo lo stesso bottone sul suo FE le vede chiare e forti!
 
Per riscontrarle, l'U2 deve, come già illustrato, uscire, rientrare nella form e premere il btn3.
 
Ve lo chiedo sui ceci: datemi una mano per venirne a capo! :-)
 
Grazie,
Stolcius
 
 
 
 
 
 
 
 
 
 

 Ecco, in questo caso,successivamente alla pressione del btn1, la vista della subform dell'U2 non cambia.
Cosa fai qui, esattamente?
 
 
 
-- 
 
ac (x=y-1)

 Cosa fai qui, esattamente?
 
Questa seconda funzione serve per gestire la chiusura di un'esercizio.
 
Passando al "corpore vili", la frm1 integra un commandButton(btn2) il cui caption, a seconda che l'esercizio precedente sia ancora aperto o chiuso, viene valorizzato con "Chiusura esercizio [Anno corrente-1]" XOR  "Revoca chiusura esercizio [Anno corrente-1]".
 
Sempre a seconda di questi due distinti stati, il tag del btn2 viene valorizzato con un valore di Enum: Chiusura/Revoca.
 
Durante l'apertura della frm1, una function (func3), richiamata dalla
Form_Load, verifica lo stato di apertura dell'esercizio[Anno corrente-1] per mezzo di un Dlookup su una specifica tabella di Log(tblLogEsercizi) e valorizza di conseguenza il btn2.
 
La pressione del btn2 comporta quanto segue:
   1)btn2 con "chiusura Esercizio..."
      a)viene aperta una Transaction;
      b)se la famigerata tbl1(quella connessa alla subform) contiene
        dei record afferenti all'esercizio [anno corrente -1](e.g. 2011) in 
        un particolare stato("[scaricato]=false"), viene effettuato 
        l'execute di "UPDATE tbl1 SET AnnoDiCompetenza=2012 WHERE
        Esercizio=2011";
      c)viene eseguito un execute "Update tblLogEsercizi SET DataChiusura=NOW"
        il quale chiude l'esercizio 2011.
      - se l'eventuale passo a) e b) vanno correttamente in porto 
        abbiamo il Commit.
    2)btn2 con "Revoca chiusura Esercizio..."
      in sintesi, viene eseguito l'ambaradan di cui sopra al contrario: 
      - risettando al 2011 l'AnnoDiCompetenza dei record trasportati
        al 2012;
      - riaprendo l'esercizio del 2011 sulla tblLogEsercizi
 
Lo so che c'è parecchia carne al fuoco, pertanto da un grazie K passiamo non a un grazie Giga, ma a un grazie Tera per l'interessamento(evito "Grazie Peta" perchè suona male!).     
 
Pensi che il problema che ho registrato sia legato al coding o si sia sbordellata  la frm1(ipotesi sempre da tener presente)?
Certo, in questa evenienza sarebbe sufficiente ricostruire la maschera ex novo.
 
Come già detto: grazie Tera, Alessandro! :-)
 
Stolcius
 
- Per aspera ad (dis)astra  
 
 
 

 Certo, in questa evenienza sarebbe sufficiente ricostruire la maschera ex novo.
La form sarebbe "sbordellata" se avesse cambiato comportamento.
Non mi sembra che questo sia il caso, il difetto mi sembra genetico.
 
-- 
 
ac (x=y-1)

 post.
[...]
 
Sembra proprio un programma scritto dalla Microsoft.
Complicazioni a non finire per eseguire una serie di processi che poi 
non sono nï¿œ tanti nï¿œ complicati.
 
Cosï¿œ a distanza mi ï¿œ difficile comprenderne appieno lo sviluppo logico.
Hai provato a disattivare la transazione?
 
Bruno
 
 

 Io vorrei capire quali sono le azioni per il "refresh" del subform di Ux.
 
Come ho spiegato nel punto precedente:
     subfrm.recordsource=FunzioneCheGeneraLaSelect()
 
--
Un salutone e grazie ancora,
Stolcius

 Bruno
 
Grazie, Bruno.
 
Un salutone,
Stolcius
 

 curioso, no?
 
No, solo normale.
=====================
 
Spiacente non poteri aiutare.
Alla prossima.
 
Bruno
 
 

 Ti ho solo chiesto di disattivare la transazione a mo' di verifica.
 
Scusami,Bruno, allora mi devi elencare le "Complicazioni a non finire[...]"(sic) 
 
 
Stolcius

 Però fa molto chic parlarne!
 
Non è quella della Microsoft(ho usato VM come mero acronimo di virtual Machine).
 
Stolcius

Stolcius Von Stolcenberg formulated the question :

1 - Hai una MainForm unbound che ne contiene una bound il cui
    RecordSource è compilato di volta in volta da una SELECT... WHERE.
    Mi sembra più semplice usare una sola Form, RecordSource tbl1,
    OnLoad della quale:
              FilterOn = True
              Filter = "[AnnoDiCompetenza]=" & Year(Now())
    ovvero:
              includere le due righe precedenti in AfterUpdate di
              una combo per la selezione dell'anno.
    Per escludere il filtro, un Button con: FilterOn = False
 
2 - Questo pare il massimo dell'assurdità:
    "
      Ad ogni corretto inserimento/modifica:
      1) frm2 viene chiusa in automatico;
      2) il focus ripassa alla frm1;
      3) viene rinvocata la funzione di popolamento della subform
    "
    Diviene tutto completamente inutile se usi una sola Form.
 
3 - Ma ancora più assurdo:
    "
    b) in caso di inserimento, la subform viene aggiornata con la nuova
    occorrenza su azione diretta dell'utente: tramite un button(btn1)
    che trigga la funzione di popolamento dela subform.
    "
 
Secondo la mia idea di semplicità mi sembra tutto una roba da matti!
Ma naturalmente il matto potrei benissimo essere io.
 
Bruno
 
 

 Secondo la mia idea di semplicità mi sembra tutto una roba da matti!
 
Guarda, il discorso della chiusura/revoca chiusura dell'esercizio(che l'utente "deve" effettuare manualmente) è un requisito funzionale.
 
Per soddisfarlo,imvho, ci  vuole un bottone .
 
Ma ti do' atto che l'uso dei valori di enum sul tag del button non onora  minimanmente la dea Semplicità.
 
Faccio un largo uso di Enum (anche per i parametri delle funzioni) e di classi anche perchè ciò mi facilita la lettura del codice in quanto "ce vedo poco"(diciamo così...).
 
E' un "de gustibus" e un "nun ce vedibus", quindi.
 
Ti ringrazio per le risposte :-)
 
Un salutone,
Stolcius




Bruno,
scusami il rincoglionimento,
ma non considerare l'ultima risposta in quanto sempre per l'effetto "talpa" mi ero perso la distinta delle tue osservazioni.
Naturalmete ciò che ho scritto si basava su le tue due ultime considerazioni e sono quindi andato fuori tema.
 
A breve avrai la risposta "derincojonizzata" :-))
 
Un saluto,
Stolcius
 

 S�, il btn1 invoca una funzione che costruisce una "SELECT * FROM tbl1 [...]" variabile - in quanto, a seconda delle impostazioni della maschera, possono aggiungersi parecchi " AND " - e lo aggancia al recordsource della subfrm.
Era quello che volevo sapere e mi sembra corretto.
 
 
-- 
 
ac (x=y-1)

 sulla generalizzata utilità della quale io nutro seri dubbi.
La VM e' uno strumento molto utile in tante occasione.
Non essere cosi "negativo" ;-{)
E comunque la VM non e' una invenzione della Microsoft.
 
 
 
-- 
 
ac (x=y-1)

     "
 
No.
Se ho scritto così mi sono spiegato male.
La form, in locale, viene sempre aggiornata automaticamente.  
 
Solo nel caso di multiutenza l'utente U2 deve aggiornare la form per
visionare i nuovi inserimenti(le modifiche, invece, vengono trasmesse automaticamente dall'Engine, ma è un opzione che voglio eliminare per via del rallentamento delle prestazioni)
 
 
Un salutone,
Stolcius

 E comunque la VM non e' una invenzione della Microsoft.
 
"sulla generalizzata utilitï¿œ della quale io nutro seri dubbi"
significa che ho dubbi che sia "sempre" utile: molte volte non lo ï¿œ, 
molte volte ï¿œ solo un vezzo.
 
Lo so che MS non l'ha inventata, l'ha solo scoperta come gadget 
aggiuntivo ai propri prodotti.
In Winserver 2003 mi pare che proprio non se ne parlasse ancora.
ï¿œ saltata fuori come HyperV dopo l'uscita di Winserver 2008 poi 
inglobata come feature nell'upgrade R2.
 
Altri produttori giï¿œ la utilizzavano da un po' di tempo, ma quelli non 
han fatto tendenza. La Microsoft sï¿œ!
 
Bruno