Inserimento dati da sottomaschera

di il
27 risposte

27 Risposte - Pagina 2

  • Re: Inserimento dati da sottomaschera

    13/10/2023 - Yuri ha scritto:


    Quelle che suggerisci sono le soluzioni che sto percorrendo, resta il fatto che nella query riesco a modificare ed inserire i dati ma dalla form no.

    Perché la query è madre + figlia

    Nel form hai madre + (madre + figlia)

    13/10/2023 - Yuri ha scritto:


      DoCmd.GoToRecord "B_000_Elementi", , acNewRec

    No ci va qualche cosa tipo me.ecc…

  • Re: Inserimento dati da sottomaschera

    La query della SubForm come ti ha detto Andrea è assurdo sia in JOIN con la Tabella Lato(1)… e nemmeno comprendo bene se le relazioni tra le Tabelle siano state correttamente impostate… 

    Secondo me stai trascurando qualche errore di base che inibisce la scrittura e non credo sia da considerare l'uso del codice per aggirare l'errore tecnico, suggerisco di capirlo prima…!

  • Re: Inserimento dati da sottomaschera

    Ho aggirato l'errore utilizzando una maschera per l'inserimento dei dati e funziona tutto correttamente… non ho ancora capito l'errore che mi dava, sicuramente è in qualche passaggio della query come dite voi.

    Grazie dell'aiuto, a presto!

    Yuri

  • Re: Inserimento dati da sottomaschera

    L'errore fa riferimento all'impostazione di una proprietà di un elemento che non è disponibile.
    Cosa che accade quando da una maschera tenti di aggiornare un elemento di una maschera che non è aperta, oppure si trova in secondo piano.

    Ed infatti da vb cerchi di impostare il setfocus di un elemento nella sottomaschera, Ma se la chiamata avviene dalla prima maschera, l'elemetno della seconda non è disponibile, anche se graficamente e visivamente sembra disponibile.

    Inoltre l'errore di fondo è avere come fonte dati della maschera principale una tabella (chiamiamola tabella 1) e come fonte dati una query. (Chiamiamola query 1)

    In realtà la fonte dati della maschera principale deve essere una query che contiene i dati della tabella 1 e della query 1, altrimenti, in fase di aggiunta di un nuovo record, non ci sarà correlazione tra i vari id, perchè quello della maschera principale rimarrà sempre lo stesso, mentre quello nella sottomaschera, dovrebbe variare in base a quello presente nella maschera principale.

    Quindi in presenza di una relazione referenziale, ti genera errore, togliendo la coerenza referenziale, non ti genera errore, ma non si sa che cosa può accadere.

    In base alle relazioni, ti potrebbe aggiungere record privi di chiave primaria collegata, modificare il primo record che trova con la chiave primaria corrispondente, impedire l'aggiunta.

    Con quello che stai tentando di fare non stai usando una maschera principale ed una sottomaschera, ma una maschera principale ed una maschera collegata, anche se si trova in una unica form.

    Quindi se vuoi usare la tipologia maschera sottomaschera, devi creare una query unica e darla in pasto alla maschera principale e collegare i campi master tra le due.

    Se invece vuoi continuare come avevi pensato, devi usare la tecnica che si usa quando si è in presenza di una maschera collegata.

    Quindi nella seconda maschera, ogni volta, dovrai posizionarti sul record giusto della prima maschera e solo dopo potrai modificare i dati della seconda, andando però contemporaneamente ad aggiornare gli id della seconda maschera e cancellare i valori immessi nella seconda maschera.

    Ma mentre nella casistica classica di maschera più maschera collegata, la cosa si risolve in modo abbastanza agevole, perchè la seconda maschera si apre solo sul record con id giusto, in presenza di entrambe le maschere, devi gestire in manuale tutti gli aggiornamenti ogni qualvolta che ti sposti da una all'altra o da un elemento all'altro.

    Fattibile, ma ci vuole molto più codice e una gestione impeccabile degli eventi tra le due maschere.

  • Re: Inserimento dati da sottomaschera

    13/10/2023 - fratac ha scritto:


    L'errore fa riferimento

    ohi ohi ohi… carissimo Fratac, … purtroppo questi sono errori di approccio ;-)

    Una logica sbagliata, un sistema fallace, etc etc etc …. insommmmmaaaaaaa le basi !!!!!

    13/10/2023 - Yuri ha scritto:


    Ho aggirato l'errore utilizzando una maschera per l'inserimento dei dati e funziona tutto correttamente… non ho ancora capito l'errore che mi dava, sicuramente è in qualche passaggio della query come dite voi.

    Grazie dell'aiuto, a presto!

    Yuri

    Ciao, come accennavo a Fratac, il tuo errore è nell'approccio e nella logica. 

    Ricorda che le cose semplici sono le più funzionali e performanti.
    Un database ben relazionato non ti deve mai portare, come in questo caso, a realizzare delle query da assegnare come recordssource alle form e subform  per inserimento aggiornamento records. 

    Referenziare le tabelle relazionate deve rispondere ad una precisa logica che devi analizzare in fase di progettazione del tuo database…  e da qui partirà tutto lo sviluppo del progetto.

    Insomma, semplifica e progetta ancor prima di sviluppare, altrimenti ti ritrovi ad “aggirare” problemi di varia natura che non hai previsto e considerato a dovere.

    Semplifica e dimenticati che esistono le query per inserire ed aggiornare i records. Le query usale solo per esporre i dati da analizzare e visualizzare o nelle form o nei report.  

    Semplifica, fai le cose normali e ti troverai meglio e meglio sarebbe sempre come prima cosa stilare un analisi del progetto sia in fase di prima realizzazione che successivamente in aggiornamento. Quando il progetto è pronto, poi realizzarlo è una passeggiata e un divertimento.

    n.b.  sono solo piccoli consigli per evitare problemi ;-)
    Buon lavoro 

  • Re: Inserimento dati da sottomaschera

    13/10/2023 - By65Franco ha scritto:


    Le query usale solo per esporre i dati da analizzare e visualizzare o nelle form o nei report

    Con le query ci fai tutto ma bisogna saperle usare.

    Se vuoi sostituire un campo relazionato tipo il cliente sui preventivi dell'intero anno, o scrivi 10 righe di codice con ciclo for  per 70 preventivi o scrivi una sql di update. Passando i parametri giusti.

    È solo un esempio.

    Come ho cercato di intuire ha messo la tabella master e una query che riprende la master + la detail e la sub detail (a_000; b_000 e d_000) va bene in visualizzazione ma non se vai ad editate un campo per cambiarne i valori.

  • Re: Inserimento dati da sottomaschera

    13/10/2023 - sihsandrea ha scritto:


    13/10/2023 - By65Franco ha scritto:


    Le query usale solo per esporre i dati da analizzare e visualizzare o nelle form o nei report

    Con le query ci fai tutto ma bisogna saperle usare.

    Se vuoi sostituire un campo relazionato tipo il cliente sui preventivi dell'intero anno, o scrivi 10 righe di codice con ciclo for  per 70 preventivi o scrivi una sql di update. Passando i parametri giusti.

    È solo un esempio.

    Come ho cercato di intuire ha messo la tabella master e una query che riprende la master + la detail e la sub detail (a_000; b_000 e d_000) va bene in visualizzazione ma non se vai ad editate un campo per cambiarne i valori.

    Ciao Andrea…. si si hai ragione in toto….

    il mio è un vizio progettuale… nei miei Db non trovi quasi mai gli oggetti query… sempre stringhe sql o come recordsource ma soprattutto da codice per assolvere a tutte le funzioni… dai recordset in select piuttosto che insert/upedate/delete etc etc etc … Ma oggetti Query non ne trovi traccia nei miei Db … mi dovrebbero prendere per i capelli (che non ho più) e costringermi
     ;-))

    Insomma … le query per me sono degli oggetti “usa e getta” che possono essere utili solo per le verifiche e i test… su queste non baserei mai lo sviluppo del progetto. 

  • Re: Inserimento dati da sottomaschera

    13/10/2023 - By65Franco ha scritto:


    sempre stringhe sql o

    Sono query… anche se non le metti in una dbgrid.

  • Re: Inserimento dati da sottomaschera

    13/10/2023 - sihsandrea ha scritto:


    13/10/2023 - By65Franco ha scritto:


    sempre stringhe sql o

    Sono query… anche se non le metti in una dbgrid.

    Beh… diciamo che prima nasce il linguaggio Sql e poi l'oggetto Query… Le Query hanno limitazioni e spesso poco performanti e duttili… da codice con la stringa Sql ci fai di tutto e di più… troppo più semplice.

    ;-)

    Ovviamente si fa per parlare… poi sai se uno non vuole scrivere in Vba, si appoggia agli oggetti e lavora solo con quelli… e va bene anche in questo modo, non c'è nulla di male…. alla fine la cosa più importante è sempre avere alla base una analisi e una progettazione fatta come si deve.

  • Re: Inserimento dati da sottomaschera

    13/10/2023 - By65Franco ha scritto:

    Beh… diciamo che prima nasce il linguaggio Sql e poi l'oggetto Query… Le Query hanno limitazioni e spesso poco performanti e duttili… da codice con la stringa Sql ci fai di tutto e di più… troppo più semplice.

    ;-)

    Ovviamente si fa per parlare… poi sai se uno non vuole scrivere in Vba, si appoggia agli oggetti e lavora solo con quelli… e va bene anche in questo modo, non c'è nulla di male…. alla fine la cosa più importante è sempre avere alla base una analisi e una progettazione fatta come si deve.

    Magari dai una letta a questo:

    https://www.access-programmers.co.uk/forums/threads/saved-queries-vs-sql-build-on-the-fly.303234/

  • Re: Inserimento dati da sottomaschera

    13/10/2023 - @Alex ha scritto:


    13/10/2023 - By65Franco ha scritto:

    Beh… diciamo che prima nasce il linguaggio Sql e poi l'oggetto Query… Le Query hanno limitazioni e spesso poco performanti e duttili… da codice con la stringa Sql ci fai di tutto e di più… troppo più semplice.

    ;-)

    Ovviamente si fa per parlare… poi sai se uno non vuole scrivere in Vba, si appoggia agli oggetti e lavora solo con quelli… e va bene anche in questo modo, non c'è nulla di male…. alla fine la cosa più importante è sempre avere alla base una analisi e una progettazione fatta come si deve.

    Magari dai una letta a questo:

    https://www.access-programmers.co.uk/forums/threads/saved-queries-vs-sql-build-on-the-fly.303234/

    Grazie Alex… ma alla fine anche in quella discussione c'è chi è a favore e chi no… sicuramente ci sono dei pro e dei contro… non saprei, la mole di dati che solitamente ho trattato non è mai stata eccessiva e non ho mai toccato con mano in termini di prestazioni, l'eventuali pregi o difetti.

    Personalmente da quando, anni e anni fa ;-),  mi insegnasti ad usare il DBEngine(0)(0), mi trovo molto bene con le stringhe Sql …
    per esempio addirittura ancor meglio e più performante eseguire un Update con DbEngine(stringa Sql) che con recordset.Edit / recordset.Update… infatti quando ti trovi all'interno di un ciclo while not.eof e aggiorni un numero elevato di records, beh… non solo alla fine va in errore ma è anche molto più pesante che eseguire una stringa sql con il DBEngine. Ho potuto constare che è almeno ? più veloce.

    Personalmente le stringhe Sql le preferisco al posto delle Query e mi ci ritrovo meglio soprattutto con i parametri, where condition, etc etc… da passare in fase di esecuzione.
    Anche con le funzioni ho riscontrato più funzionalità e duttilità rispetto alle Query… riscontro dei limiti con le Query e poi magari al cambio di versione, come è già capitato, non ritrovi più per esempio le Column per le combobox. In quest'ultimo caso aver usato le stringhe Sql al posto delle Query è risultato un vantaggio.

    Non le odio e non le disprezzo le Query, ma preferisco usare comunque le stringhe Sql, ormai ho preso questo vizio ;-)) 

  • Re: Inserimento dati da sottomaschera

    13/10/2023 - By65Franco ha scritto:


    Ovviamente si fa per parlare… poi sai se uno non vuole scrivere in Vba, si appoggia agli oggetti e lavora solo con quelli… e va bene anche in questo modo, non c'è nulla di male…. alla fine la cosa più importante è sempre avere alla base una analisi e una progettazione fatta come si deve.

    Anche se è un po OT, ragioni in termini di access.

    Una query è una interrogazione per estrapolare e/o manipolare i dati. Che l'oggetto si chiami anche query (tquery in delphi o fdquery sempre in delphi con diredac) è solo una praticità (come chiamare la tabella clienti “tbclienti”, solo perché rende l'idea di cosa si tratta).

    Trasparente all'utente, anche l'oggetto tabella è una query che si limita ad una sql del tipo “select * from tabella”.

    L'oggetto, ti permette, senza dover scrivere la stringa sql di cambiare le proprietà della sql.

    Se nella proprietà metti il database, l'oggetto scrive la sql relativa alla connessione.

    Quando setti la proprietà nell'oggetto per l'ordinamento aggiungi alla sql “order by…” e così via.

    L'unica pesantezza è la unit dell'oggetto (ininfluente).

    L'inganno che ti porti dietro deriva da access dove con una linguetta aggiungi il campo, ne metti il criterio ecc… se dai uno sguardo a mysql, firebird ecc, non hai la griglietta dove inserire il campo ed il criterio ma devi costruirti l'sql con update, insert, select e l'uso di where, union, join ecc…

    Tutto si traduce in un comando sql, che sia in un ambiente grafico o da terminale.

  • Re: Inserimento dati da sottomaschera

    14/10/2023 - sihsandrea ha scritto:


    Tutto si traduce in un comando sql, che sia in un ambiente grafico o da terminale.

    Ovviamente si … è chiaro il concetto.

    Grazie per la chiacchierata e le info … ;-)

Devi accedere o registrarti per scrivere nel forum
27 risposte