Editare un recordset su una maschera richiamata

di
rinh0wrz
il
19 risposte

19 Risposte - Pagina 2

  • O
    OsvaldoLaviosa
    Super Famoso
    Iscritto da
    apr, 2012
    Messaggi:
    7503

    Re: Editare un recordset su una maschera richiamata

    Questo link
    https://support.office.com/it-it/article/modificare-dati-in-una-query-6ca3edfc-6d66-4d90-8219-c2b258d5bed7
    dice:
    Quando è possibile modificare i dati di una query
    È sempre possibile modificare i dati di una query quando la query si basa solo su una tabella oppure su due tabelle caratterizzate da una relazione uno-a-uno tra loro.

    Quando non è possibile modificare i dati di una query
    ...
    La query si basa su tre o più tabelle caratterizzate da una relazione molti-a-uno-a-molti.
  • R
    rinh0wrz
    Utente Attivo
    Iscritto da
    gen, 2019
    Messaggi:
    52

    Re: Editare un recordset su una maschera richiamata

    Mi sembra che vengano rispettati tutti i requisiti che esponi:

    1. Maschera aperta in Edit
    2. Ho inserito tutte le relazioni tra le tabelle coinvolte

    Quello che non conosco di Access, lo vengo a chiedere qui apposta
  • @Alex
    @Alex
    Super Famoso
    Iscritto da
    feb, 2012
    Messaggi:
    8752

    Re: Editare un recordset su una maschera richiamata

    OsvaldoLaviosa ha scritto:

    Questo link
    https://support.office.com/it-it/article/modificare-dati-in-una-query-6ca3edfc-6d66-4d90-8219-c2b258d5bed7
    dice:
    Quando è possibile modificare i dati di una query
    È sempre possibile modificare i dati di una query quando la query si basa solo su una tabella oppure su due tabelle caratterizzate da una relazione uno-a-uno tra loro.

    Quando non è possibile modificare i dati di una query
    ...
    La query si basa su tre o più tabelle caratterizzate da una relazione molti-a-uno-a-molti.
    Osvaldo serve capire quello che si legge...
    Fai una prova con 2 tabelle relazionate (1-M) e metti tutti i campi di entrambe.. poi ci dici se sono editabili e quali e soprattutto da che parte della relazione... risultano editabili.
    Poi ne parliamo...

    Quanto dicevo è infatti ben spiegato nell'articolo e vale anche per l'inserto di un new: 
    Assicurarsi che il campo dal lato "uno" includa un valore. 
È possibile modificare il campo di join dal lato "molti" 
solo se è incluso un valore in tale campo dal lato "uno".
  • O
    OsvaldoLaviosa
    Super Famoso
    Iscritto da
    apr, 2012
    Messaggi:
    7503

    Re: Editare un recordset su una maschera richiamata

    @Alex, sei andato a "capare" proprio il caso limite di confine, che io avevo (in altre parole) previsto. Io ragiono così:
    1. Una query su una sola tabella è modificabile in tutti i suoi campi.
    2. 2 tabelle relazionate uno-a-molti, alcuni campi sono modificabili, altri no.
    3. A mano a mano che si aggiungono altre tabelle relazionate, la modificabilità dei campi diventa sempre più impossibile.

    Considerato che il caso 1., a questo punto perché non agire direttamente in tabella?
    Nel Caso 2.: vale la pena arrovellarsi il cervello per cercare di capire quali campi sì, quali no?
    Morale dell'idea generale che mi sono fatto io: evitare di usare le query per modificare dati. Le query "di selezione", se non altro per la loro funzione primordiale, servono per RESTITUIRE RISULTATI.
  • @Alex
    @Alex
    Super Famoso
    Iscritto da
    feb, 2012
    Messaggi:
    8752

    Re: Editare un recordset su una maschera richiamata

    OsvaldoLaviosa ha scritto:

    @Alex, sei andato a "capare" proprio il caso limite di confine, che io avevo (in altre parole) previsto. Io ragiono così:
    1. Una query su una sola tabella è modificabile in tutti i suoi campi.
    2. 2 tabelle relazionate uno-a-molti, alcuni campi sono modificabili, altri no.
    3. A mano a mano che si aggiungono altre tabelle relazionate, la modificabilità dei campi diventa sempre più impossibile.
    Osvaldo quello che stai dicendo di fatto non significa NULLA.
    Le Query in MultiJoin si usano ed hanno determinati scopi.
    I Campi ricavati lato 1 servono per l'AutoLookUp dei Dati, per evitare che tu nelle maschere debba mettere un DlookUp che rallenta molto... è ovvio che quei dati attinenti al Lato 1, non si devono modificare ma fanno parte della Query che popola la Maschera e che lo sviluppatore gestirà affinchè siano modificabili i dati che hanno la possibilità di essere modificati...!
    E' questione di SAPERE cosa fanno le Query e come si usano, e non Copia/Incollare Wikipedia(inquesto caso Supporto MS) senza aver nemmeno capito di cosa si parla.
    La medesima cosa si fa per le aggiunte... ma è ovvio che questo processo si deve legare all'utilizzo della Maschera basata su Query(multiJoin) in contesti adeguati che ne consentono la Valorizzazione dei Campi CHIAVE, gli altri sono intoccabili.
    Quindi le Query in MultiJoin si usano anche per ADDNEW se la Maschera basata sulla Query in questione è SubForm di una Form basata a sua volta sui Dati lato 1, perchè la PK(lato1) e la FK(Lato M) vengono mantenute valorizzate, proprio per come lavorano Form/SubForm in MasterDetail.

    OsvaldoLaviosa ha scritto:

    Considerato che il caso 1., a questo punto perché non agire direttamente in tabella?
    Nel Caso 2.: vale la pena arrovellarsi il cervello per cercare di capire quali campi sì, quali no?
    Morale dell'idea generale che mi sono fatto io: evitare di usare le query per modificare dati. Le query "di selezione", se non altro per la loro funzione primordiale, servono per RESTITUIRE RISULTATI.
    Osvaldo... io spero che il tuo approccio possa migliorare... perchè manca tecnicamente di conoscenza e riduce la possibilità di comprendersi quasi a zero, e quello che dici è fortemente sbagliato nel senso che tendi ad Assolutizzare in modo assurdo un concetto che invece ha una Flessibilità estrema, e si sfrutta proprio per questo.
    Chiaramente sei libero di operare come il tuo metodo ti suggerisce, ma almeno non diffonderlo.
Devi accedere o registrarti per scrivere nel forum
19 risposte