+ Rispondi al messaggio
Visualizzazione dei risultati da 1 a 10 su 10

Parametri insufficienti con query parametrica

  1. #1
    h0m3r non è in linea Scolaretto
    Ciao a tutti,
    come da titolo vba mi da un errore "3061 - parametri insufficienti previsto 2" quando va a leggere i dati da una query parametrica. Se l'intervallo di data all'interno della query viene inserito manualmente
    between #01/01/2021# and #31/07/2021#
    
    l'esecuzione del codice avviene liscia senza intoppi, mentre se passo l'intervallo di data da 2 caselle di testo (configurate come data/ora) su una Form mi da l'errore.
    Public Function Controlla_Sospesi_Broker()
        Dim db As Database
        Dim rsSO01, rsSO02, rsRaffronto As Recordset
        Dim strSO01, strSO02, strRaffronto As String
        
        Set db = CurrentDb
        Set rsSO01 = db.OpenRecordset("qrySo01", dbOpenDynaset)        'ERRORE RUNTIME 3061
        Set rsSO02 = db.OpenRecordset("qrySO02", dbOpenDynaset)
        Set rsRaffronto = db.OpenRecordset("tblRaffrontoSospesoBroker", dbOpenDynaset)
    
    Da cosa può dipendere e come posso risolvere questo errore?
    Ultima modifica di h0m3r; 24-08-2021 10:29 

  2. #2
    Pubblica la SQL della query, altrimenti non si può ragionare su niente.

  3. #3
    h0m3r non è in linea Scolaretto
    Quote Originariamente inviato da Phil_cattivocarattere Visualizza il messaggio
    Pubblica la SQL della query, altrimenti non si può ragionare su niente.
    Ecco la query:
    SELECT tblSospesoBroker.ID, tblSospesoBroker.AGENZIA, tblSospesoBroker.GESTIONE, tblSospesoBroker.CODICE_NATURA, tblSospesoBroker.DATA_CONTABILITA, tblSospesoBroker.DATA_ESIGIBILITA, tblSospesoBroker.IMPORTO, tblSospesoBroker.STATO, tblSospesoBroker.Log, tblSospesoBroker.POLIZZA, tblSospesoBroker.OSSERVAZIONE_CONTABILE, tblSospesoBroker.IDUTENZA_CREAZIONE, tblSospesoBroker.NOTE, tblSospesoBroker.IDTITOLO, tblSospesoBroker.IDINCASSO, tblSospesoBroker.IDTITOLOCOLLEGATO, tblSospesoBroker.AGENZIA_COMPETENZA, tblSospesoBroker.CODICE_RUI, tblSospesoBroker.DESCRIZIONE_INTERMEDIARI, tblSospesoBroker.DataContabilita, tblSospesoBroker.Rif, tblSospesoBroker.CMP
    FROM tblSospesoBroker
    WHERE (((tblSospesoBroker.DataContabilita) Between [Forms]![Frontespizio]![txtDataDal] And [Forms]![Frontespizio]![txtDataAl]) AND ((tblSospesoBroker.Rif)<>'3905' And (tblSospesoBroker.Rif)<>'3906' And (tblSospesoBroker.Rif)<>'3991' And (tblSospesoBroker.Rif)<>'3992' And (tblSospesoBroker.Rif)<>'3A2S' And (tblSospesoBroker.Rif)<>'3AFA' And (tblSospesoBroker.Rif)<>'3EKR'));
    

  4. #4
    Quote Originariamente inviato da h0m3r Visualizza il messaggio
    Public Function Controlla_Sospesi_Broker()
        Dim db As Database
        Dim rsSO01, rsSO02, rsRaffronto As Recordset
        Dim strSO01, strSO02, strRaffronto As String
    
    Non va bene dichiarare così le variabili, perché solo l'ultima della riga prende il tipo giusto, le altre sono implicitamente Variant. Devi specificare per tutte il tipo, ogni volta.

  5. #5
    h0m3r non è in linea Scolaretto
    Quote Originariamente inviato da Phil_cattivocarattere Visualizza il messaggio
    Non va bene dichiarare così le variabili, perché solo l'ultima della riga prende il tipo giusto, le altre sono implicitamente Variant. Devi specificare per tutte il tipo, ogni volta.
    Premetto che da quando ho iniziato ho sempre dichiarato, magari sbagliando, le variabili in questo modo senza aver avuto problemi. A parte ciò il problema purtroppo non dipende da questo...

  6. #6
    L'avatar di @Alex
    @Alex non è in linea Moderatore Globale
    Quote Originariamente inviato da h0m3r Visualizza il messaggio
    Premetto che da quando ho iniziato ho sempre dichiarato, magari sbagliando, le variabili in questo modo senza aver avuto problemi. A parte ciò il problema purtroppo non dipende da questo...
    Non potrai mai avere problemi dichiarandole VARIANT... occupano solo per 10 in memoria inutilmente ma essendo variant si adattano a tutto, ed è il motivo per cui occupa 22Bytes(24 in sistemi 64bits).

    Chiaramente questo non significa sia un modo pulito di lavorare, ed ovviamente non sono loro il problema, ma raccontano molto...

    La tua Query, che NON E' PARAMETRICA, ma semplicemente con WHERE CONDITION, le Query Parametriche usano i PARAMETERS come dice la parola stessa, è in ogni caso scritta molto male... ha un sacco di criteri in AND negato dal [<>] sullo stesso campo che rende anche complesso leggerla...!

    Esiste la possibilità di usare la Clausola NOT IN ('3991','3992','3SA2',....ecc...)
    Aggiungo un dubbio sui criteri DATA che utilizzi con il riferimento IMPLICITO inserito nella query... non molto intelligente a livello prestazionale e di scalabilità.
    Se avessi un RDBMS tipo SQL_Server, sarebbe proprio sbagliato in quanto il predicato risulterebbe non risolvibile ServerSide e creerebbe solo entropia di dati ed abbattimento prestazionale, chiaramente funzionerebbe, come per i Type Variant...

    Meglio quindi query Parametriche appunto con i Parametri, e, diamo anche per scontato che la Form Frontespizio sia APERTA...!

    Insomma io fossi in te semplificherei la Query così, almeno per capire inizialmente
    SELECT * FROM tblSospesoBroker
    WHERE (tblSospesoBroker.DataContabilita Between cDate([Forms]![Frontespizio]![txtDataDal]) AND 
                                                    cDate([Forms]![Frontespizio]![txtDataAl])) AND 
           tblSospesoBroker.Rif NOT IN (.... il tuo elenco delle esclusioni)
    
    Usando i PARAMETERS:
    PARAMETERS DateINI Long, DateEND Long;
    SELECT * FROM tblSospesoBroker
    WHERE (tblSospesoBroker.DataContabilita Between [DateINI] AND [DateEND]) AND 
           tblSospesoBroker.Rif NOT IN (.... il tuo elenco delle esclusioni)
    
    I parameter di date sono Long in quanto in Italia abbiamo gg/mm/aaaa e JET vuole il formato ISO o Anglosassone...
    Da usare poi
    Dim qdf As DAO.QueryDef
    Dim rs  As DAO.Recordset
    Set qdf=CurrentDb.QueryDefs("NomeQuery")
    With qdf
        .Parameters!DateINI=Clng(Me!NomeTextboxDa)
        .Parameters!DateEND=cLng(Me!nomeTextBoxA)
        Set rs= .OpenRecordset
        ' se devi associarla ad una Maschera o ad una ListBox
        ' Set Forms("Nomeform").Recordset= .OpenRecordset
        ' Set Me!NomeListBox.Recordset= .OpenRecordset
    End With
    
    Ultima modifica di @Alex; 24-08-2021 13:29 
    ℹ️ Leggi di più su @Alex ...

  7. #7
    Quote Originariamente inviato da h0m3r Visualizza il messaggio
    ...A parte ciò il problema purtroppo non dipende da questo...
    Vero, visto che anche dichiarandole giuste il problema c'è.
    Non uso mai quelle query finto-parametriche e vorrei chiedere a te se hanno mai funzionato perché ho provato a riprodurre la tua situazione, molto più semplificata, e funziona solo se apro la query con il doppioclick, non se apro il recordset: succede esattamente quello che succede a te.
    Meglio usare le query quelle veramente parametriche, che in SQL iniziano con "PARAMETERS". Usi un oggetto QueryDef, valorizzi i parametri della collection Parameters e poi chiami il metodo OpenRecordset (sempre dell'oggetto querydef, non del database).
    Oppure costruisci la stringa SQL già con i valori giusti, che forse è la via più semplice.
    Qualcuno vuole tirare in ballo ADO? Io no, perché non lo so usare.

  8. #8
    L'avatar di @Alex
    @Alex non è in linea Moderatore Globale
    Perchè ADO cosa c'entra... leggi sopra ho integrato.
    ℹ️ Leggi di più su @Alex ...

  9. #9
    Quote Originariamente inviato da @Alex Visualizza il messaggio
    Perchè ADO cosa c'entra... leggi sopra ho integrato.
    Oh... vedo ora che c'è proprio l'esempio dei parameters di querydef.
    ADO? No, non c'entra niente con quello che hai scritto ma per quel poco che so/ricordo permette la gestione di queste cose con estrema flessibilità e quasi a prova di errore. Vediamo se trovo un thread in cui ... vediamo... niente, non lo trovo, ovviamente. Era un thread in cui Gibra invitava a scrivere le query in modo "più moderno" (non ricordo le parole precise), ma non lo trovo e quindi... niente. Però a mio avviso, pur non citando ADO, non poteva che riferirsi all'uso di ADO.
    Partire da qui https://masterdrive.it/microsoft-acc...35/#post342577, con un richiamo anche qui https://masterdrive.it/microsoft-acc...tml#post342927 ma quella che calza alla perfezione è questa https://masterdrive.it/microsoft-acc...tml#post371619
    Ultima modifica di Phil_cattivocarattere; 24-08-2021 14:11 

  10. #10
    h0m3r non è in linea Scolaretto
    Quote Originariamente inviato da @Alex Visualizza il messaggio
    Non potrai mai avere problemi dichiarandole VARIANT... occupano solo per 10 in memoria inutilmente ma essendo variant si adattano a tutto, ed è il motivo per cui occupa 22Bytes(24 in sistemi 64bits).

    Chiaramente questo non significa sia un modo pulito di lavorare, ed ovviamente non sono loro il problema, ma raccontano molto...

    La tua Query, che NON E' PARAMETRICA, ma semplicemente con WHERE CONDITION, le Query Parametriche usano i PARAMETERS come dice la parola stessa, è in ogni caso scritta molto male... ha un sacco di criteri in AND negato dal [<>] sullo stesso campo che rende anche complesso leggerla...!

    Esiste la possibilità di usare la Clausola NOT IN ('3991','3992','3SA2',....ecc...)
    Aggiungo un dubbio sui criteri DATA che utilizzi con il riferimento IMPLICITO inserito nella query... non molto intelligente a livello prestazionale e di scalabilità.
    Se avessi un RDBMS tipo SQL_Server, sarebbe proprio sbagliato in quanto il predicato risulterebbe non risolvibile ServerSide e creerebbe solo entropia di dati ed abbattimento prestazionale, chiaramente funzionerebbe, come per i Type Variant...

    Meglio quindi query Parametriche appunto con i Parametri, e, diamo anche per scontato che la Form Frontespizio sia APERTA...!

    Insomma io fossi in te semplificherei la Query così, almeno per capire inizialmente
    SELECT * FROM tblSospesoBroker
    WHERE (tblSospesoBroker.DataContabilita Between cDate([Forms]![Frontespizio]![txtDataDal]) AND 
                                                    cDate([Forms]![Frontespizio]![txtDataAl])) AND 
           tblSospesoBroker.Rif NOT IN (.... il tuo elenco delle esclusioni)
    
    Usando i PARAMETERS:
    PARAMETERS DateINI Long, DateEND Long;
    SELECT * FROM tblSospesoBroker
    WHERE (tblSospesoBroker.DataContabilita Between [DateINI] AND [DateEND]) AND 
           tblSospesoBroker.Rif NOT IN (.... il tuo elenco delle esclusioni)
    
    I parameter di date sono Long in quanto in Italia abbiamo gg/mm/aaaa e JET vuole il formato ISO o Anglosassone...
    Da usare poi
    Dim qdf As DAO.QueryDef
    Dim rs  As DAO.Recordset
    Set qdf=CurrentDb.QueryDefs("NomeQuery")
    With qdf
        .Parameters!DateINI=Clng(Me!NomeTextboxDa)
        .Parameters!DateEND=cLng(Me!nomeTextBoxA)
        Set rs= .OpenRecordset
        ' se devi associarla ad una Maschera o ad una ListBox
        ' Set Forms("Nomeform").Recordset= .OpenRecordset
        ' Set Me!NomeListBox.Recordset= .OpenRecordset
    End With
    
    Grazie dei preziosi suggerimenti, si impara sempre qualcosa .

+ Rispondi al messaggio

Potrebbero interessarti anche ...

  1. Risposte: 10
    Ultimo Post: 14-06-2021, 15:45
  2. Query parametrica - parametri da casella combinata
    Da Beppe Di Zega nel forum Microsoft Access
    Risposte: 3
    Ultimo Post: 24-08-2016, 17:14
  3. Risposte: 9
    Ultimo Post: 25-09-2015, 10:54
  4. Risposte: 18
    Ultimo Post: 12-02-2014, 13:35
  5. Query parametrica filtrata da molti parametri
    Da ncl3 nel forum Microsoft Access
    Risposte: 12
    Ultimo Post: 31-05-2011, 09:41