Trasporto dati da query a tabella

di il
16 risposte

Trasporto dati da query a tabella

I dati del mio recordset si trovano in una query oltretutto nidificata.
Questo non mi consente (o comunque ho molta difficoltà a farlo) di manipolarli tramite il metodo OpenRecordset e di portarli in maschera con il comando Forms!NomeMaschera.RecordSource = NomeQueryAggiornata.
Ho provato a convertire la query originale in una tabella mediante INSERT INTO ma anche questo non è cosa facile; Access trova sempre un ostacolo da mettermi fra le ruote.
Si noti che la query originale posso visualizzarla in maschera tranquillamente e senza errori.
Sto sbagliando strada?
Sono in un vicolo cieco.
Potete darmi un consiglio?

Grazie a chi vorrà rispondermi.
Antonio Cuomo

16 Risposte

  • Re: Trasporto dati da query a tabella

    Detta così... è incomprensibile.
    Definisci "Nodificata", il senso usuale è che è costituita da SubQuery...?
    Se la query Restituisce dati, ovvero funziona, non può essere un problema ad associarla ad una Maschera.
    Se lo è devi spiegare in cosa si traduce il problema nello specifico.
    Poi parli di Recordset... ma se la Query è "nidificata" per come l'ho intesa non è editabile, quindi la manipolazione è impossibile.

    Cosa devi fare e come lo stai facendo...?
  • Re: Trasporto dati da query a tabella

    Sì, in effetti ho una query che utilizza un'altra query e mi lavora bene.
    La maschera associata visualizza bene i dati ma ho necessità di modificare in itinere la base dei dati proprio partendo da questa stessa query per poi riproporla nella stessa maschera.
    Per questo motivo ho ben pensato di congelare i dati in una tabella mediante INSERT INTO e ripartire da questa.... macché, mi da mille problemi.
  • Re: Trasporto dati da query a tabella

    Se la tua maschera mostra Dati in ReadOnly in seguito alla Query con SubQuery, ovviamente non sono editabili.
    Puoi in questo caso aprire una esterna Maschera sul Record specifico ed editarlo, oppure aprire la maschera sui Record della Query editabile ovviamente omettendo la Sottoquery ed i relativi dati.

    Puoi omettere la sottoquery inserendo dei Controlli nella maschera principale tipo Dlookup, renderanno la maschera forse un po meno performante ma editabile.

    Quello che non puoi fare o è meglio evitare è creare una Tabella come appoggio... lascia stare.
  • Re: Trasporto dati da query a tabella

    Prima di intraprendere qualunque nuova strada mi piacerebbe esporti bene il mio progetto allo scopo di avere eventualmente altri buoni consigli:
    Nella mia maschera ho un elenco di persone estratte da una lista archiviata.
    In una maschera accanto ogni persona viene accoppiata con un'altra della stessa lista perché formeranno una coppia di sposi.
    Nel record di entrambi, allo scopo di poterli legare, verrà inserito l'ID dell'altro in un campo chiamato ID_Partner.
    Il mio gol è costruire una nuova lista di record dove gli sposi sono accoppiati a due a due con in mezzo un rigo vuoto.
    In fine visualizzare nella stessa maschera la nuova tabella che possa essere anche passata al report di stampa. Era per questo che mi piaceva l'idea di creare una nuova tabella.
    Ti ringrazio sin d'ora per qualunque altro tuo contributo.
  • Re: Trasporto dati da query a tabella

    A me non è chiaro se tu preferisci tracciare anche uno Storico di MOLTI accoppiamenti che potrebbero verificarsi nel corso del tempo oppure no. Intendo dire in concreto se hai una lista Persone:
    Renzo
    Paolo
    Carlo
    Rodrigo
    Lucia
    Susanna
    Anna
    Mettiamo che oggi Renzo e Lucia sono una coppia. Domani Lucia lascia Renzo e fa coppia con Rodrigo. Tu preferisci SOSTITUIRE Rodrigo a Renzo oppure tracci entrambe le coppie Renzo-Lucia, Rodrigo-Lucia (magari con un campo DataCoppia)?

    antocuomo ha scritto:


    Il mio gol è costruire una nuova lista di record dove gli sposi sono accoppiati a due a due con in mezzo un rigo vuoto.
    Puoi spiegare concretamente cosa vuol dire questo?

    antocuomo ha scritto:


    In fine visualizzare nella stessa maschera la nuova tabella che possa essere anche passata al report di stampa.
    Non capisco. Spiega tutto concretamente e con nomi propri di maschera, tabella, campi...

    antocuomo ha scritto:


    Era per questo che mi piaceva l'idea di creare una nuova tabella.
    Anch'io trovo errata l'idea di creare una nuova tabella.
  • Re: Trasporto dati da query a tabella

    No Osvaldo. Questo è un app per la mia parrocchia.
    I giovani devono sposarsi. Il lavoro serve per individuare le coppie.
  • Re: Trasporto dati da query a tabella

    Quindi immaginando la tua tabella compilata così:
    Renzo | Lucia
    Paolo | Susanna
    Carlo | Anna
    Rodrigo | (vuoto)
    Lucia | Renzo
    Susanna | Paolo
    Anna | Carlo
    che vuol dire

    antocuomo ha scritto:


    Il mio gol è costruire una nuova lista di record dove gli sposi sono accoppiati a due a due con in mezzo un rigo vuoto.
    In fine visualizzare nella stessa maschera la nuova tabella che possa essere anche passata al report di stampa.
    Forse vuoi dire che vuoi vedere le coppie scritte una volta sola?
    Poi che significa "in mezzo un rigo vuoto"?
  • Re: Trasporto dati da query a tabella

    antocuomo ha scritto:


    Prima di intraprendere qualunque nuova strada mi piacerebbe esporti bene il mio progetto allo scopo di avere eventualmente altri buoni consigli:
    Nella mia maschera ho un elenco di persone estratte da una lista archiviata.
    In una maschera accanto ogni persona viene accoppiata con un'altra della stessa lista perché formeranno una coppia di sposi.
    Nel record di entrambi, allo scopo di poterli legare, verrà inserito l'ID dell'altro in un campo chiamato ID_Partner.
    Il mio gol è costruire una nuova lista di record dove gli sposi sono accoppiati a due a due con in mezzo un rigo vuoto.
    In fine visualizzare nella stessa maschera la nuova tabella che possa essere anche passata al report di stampa. Era per questo che mi piaceva l'idea di creare una nuova tabella.
    Ti ringrazio sin d'ora per qualunque altro tuo contributo.
    Diciamo che avrai alcune persone con Id_Partner=Null ed altre con Id_Partner=xx, si spera che in ID=xx ci sia il corretto riferimento incrociato altrimenti fai dei triangoli

    Scherzi a parte, la questione riga vuota nelle maschere è un problema, non la puoi gestire... dovresti darti una Regola, in caso di coppie il Record MASTER è quello della Femmina(tanto comanda sempre lei) quindi nascondi il Record del Maschio, e riporti nel campo Calcolato con un DlookUp il Nome+Congome del Corrispondente Id_Partenr e vedi le accoppiate.
    Non hai alternative a costruirti un Criterio di MASTER tra i 2 Nella coppia, altrimenti non sai mai se è visualizzato prima o dopo...!
    Nella Query dovrai solo inserire un Criterio che esclude i Record la dove Id_Partenr NON è NULL e Sesso=Machio(se trovi un criterio migliore al'interno dei campi accoppiati è meglio ma devi trovarlo tu...)

    La stessa cosa la userai nei Report...
  • Re: Trasporto dati da query a tabella

    In attesa di una risposta che completi il "mio" quadro cognitivo, volendo seguire la logica della Femmina (capo famiglia), si può decidere di compilare solo i record delle femmine con il campo IDPartner. Poi con una query dove IDPartner=null si ottengono le sole coppie. Idem per il report che poggerebbe sulla query.
    In base a questo mio ragionare però dei Maschi non si saprebbe chi è Sposato, chi Single. Allora un campo Sì/No Sposato potrebbe risolvere.
    Ammesso io abbia capito l'intero scenario.
  • Re: Trasporto dati da query a tabella

    OsvaldoLaviosa ha scritto:


    In attesa di una risposta che completi il "mio" quadro cognitivo, volendo seguire la logica della Femmina (capo famiglia), si può decidere di compilare solo i record delle femmine con il campo IDPartner. Poi con una query dove IDPartner=null si ottengono le sole coppie. Idem per il report che poggerebbe sulla query.
    In base a questo mio ragionare però dei Maschi non si saprebbe chi è Sposato, chi Single. Allora un campo Sì/No Sposato potrebbe risolvere.
    Ammesso io abbia capito l'intero scenario.
    Quindi per non mettere ID_Partner nel maschio, cosa poco sensata, aggiungi un campo Sposato che però non ti da lo stato di aggregazione istantanea...?
    Insomma... ragionamento sicuramente discutibile.

    Metti i riferimenti incrociati come deve essere, estrai i NULL ed ottienni i SINGLE, Estrai i NOT NULL e nascondi i Maschi ed ottieni le coppie valorizzando il campo ID_Partner... con il Dlookup... cosa che serve sempre.
    A me pare Logico e semplice, se domani vuoi usare i Maschi come MASTER lo puoi fare, se poi si sposano persone dello stesso sesso, come dicevo va individuato un CRITERIO diverso e si può usare un Campo definito Master da valorizzare a True/False.
  • Re: Trasporto dati da query a tabella

    Sono contento che la cosa vi intriga, ma una parte delle vostre perplessità è già fugata in quanto le persone (M ed F) si sono già iscritte per il matrimonio ed ognuna ha già indicato il proprio partner ancor prima di entrare nella Query ed il campo "id_partner" già indica chi deve essere lo sposo/a.
    Il mio problema è stampare a video e poi su carta le esatte coppie in successione C1(M) altro rigo C1(F) poi un rigo vuoto solo per una questione estetica. Successivamente C2(M) altro rigo C2(F) e rigo vuoto.............
    Poiché i promessi sposi per una serie di motivi, non si sono iscritti contemporaneamente in successione, dovrò essere io a cercarmeli con un algoritmo ad hoc.
    Il problema è che la query non è utilizzabile in quanto "non editabile" (vi sono altre sub-query incorporate) per cui devo lavorare sui campi a video (Me![campo] per intenderci) per creare una nuova tabella. .....Credo.
    Per passare da record a record posso utilizzare sicuramente
    DoCmd.RunCommand acCmdRecordsGoToNext o First o Last, ma per tornare al record appena lasciato (all'interno di un loop), come si procede?
    Esiste l'equivalente di rs.bookmark ?
    Al rigo vuoto (separatore) ci posso anche rinunciare, lo risolvo con il colore alternativo.
  • Re: Trasporto dati da query a tabella

    Per me la storia del "rigo vuoto" potrebbe essere un CampoX che lasci vuoto nella stessa tabella, poi nel report decidi di piazzarlo sotto la coppia.

    antocuomo ha scritto:


    Poiché i promessi sposi per una serie di motivi, non si sono iscritti contemporaneamente in successione, dovrò essere io a cercarmeli con un algoritmo ad hoc.
    Puoi spiegare questa cosa che io non la capisco? Qualche esempio pratico aiuterebbe, magari utilizza gli stessi nomi che ho indicato io prima.
    Forse serve qualche campo di tipo data e magari non solo uno...penso ad esempio a DataPromessa, DataMatrimonio...non so se ho colto il senso del tuo problema!!!

    P.S.
    Eppure io taglierei la testa al toro con una 2a tabella Coppie avente i seguenti campi:
    IDCoppia (PK)
    DataPromessa
    DataMatrimonio
    IDPartner1 (FK)
    IDPartner2 (FK)
    CampoVuoto

    In IDPartner1 ci metti una casella combinata che filtra (secondo il criterio di @Alex) le Femmine. In IDPartner2 casella combinata che filtra i Maschi. Oppure con congrua filtratura in base a un campo aggiuntivo.
    Si può decidere che le relazioni tra Persone e Coppie siano di tipo uno-a-uno per non commettere errori.
    L'utente scrive i dati soltanto dentro maschera Coppie, quindi sfrutta l'evento "Non in elenco" per aggiornare Persone. Trovo che i campi di Coppie da me indicati sono anche non omogenei con Persone, ecco perchè suggerisco la 2a tabella.
    Non so se ho colto il senso della problematica.
  • Re: Trasporto dati da query a tabella

    É molto semplice:
    ID
  • Re: Trasporto dati da query a tabella

    É molto semplice:
    ID----NOME----------ID_PARTNER
    22----Giovanni----------55
    33----Carlo--------------77
    55----Emilia-------------22
    44----Antonietta--------66
    66----Alfredo------------44
    77----Rosa---------------33

    Risultato finale:
    22----Giovanni----------55
    55----Emilia-------------22

    33----Carlo--------------77
    77----Rosa---------------33

    66----Alfredo------------44
    44----Antonietta--------66
Devi accedere o registrarti per scrivere nel forum
16 risposte