Newsgroup: it.comp.appl.access
Titolo: Access 2003 + combo box in cascata basate su stored procedure parametriche

In un ADP ho una form (basata su stored procedure parametrica) che contiene 
3 combo box unbound, le quali devono aggiornarsi in cascata.
Tutte le combo sono basate su stored procedure.
La stored procedure su cui si basa la seconda combo ha un parametro al quale 
dovrei passare il valore della prima combo.
La stored procedure su cui si basa la terza combo ha un parametro al quale 
dovrei passare il valore della seconda combo.
Come origine riga della seconda combo ho messo il seguente codice:
  EXEC sp_Seconda_Combo @param1 = [Forms]![nomedellaform]![combo1]
Come origine riga della terza combo ho messo il seguente codice:
  EXEC sp_Terza_Combo @param1 = [Forms]![nomedellaform]![combo2]
Sia per sp_Seconda_Combo che per sp_Terza_Combo, il parametro ha il valore 
di default uguale a NULL. Questo serve ovviamente nel codice T-SQL della 
stored procedure per decidere se applicare un filtro alla SELECT che sta 
dentro la stored procedure oppure no.
Dopo avere mandato in esecuzione la form, la prima volta che apro la seconda 
o la terza combo ottengo il seguente messaggio di errore: "Istruzione SQL 
non valida. Controllare il filtro su server per l'origine record della maschera."
Inoltre l'elenco della combo che ho aperto è vuoto.
Ci tengo a precisare che l'errore si verifica solo alla prima apertura della 
combo, mentre l'elenco della combo rimane sempre vuoto.
Ho provato a fare del debug, ma pare che l'errore non sia scatenato dal codice.
Visto che il problema sembra spostarsi su SQL, ho provato a modificare l'origine 
riga di una delle due combo incriminate impostando un parametro con valore 
fisso, nel seguente modo:
  EXEC sp_Seconda_Combo @param1 = 84
In questo caso la combo non restituisce errore ed il relativo elenco di valori 
risulta correttamente filtrato in base al valore che ho inserito io (84).
Allora ho fatto un altro test.
Se mando in esecuzione direttamente sp_Seconda_Combo o sp_Terza_Combo con 
un doppio clic dalla finestra database, mi viene ovviamente richiesto di 
immettere il parametro, io non metto niente, e SQL mi ritorna tutti i record 
senza filtro.
Se provo ad inserire a mano un valor mi vengono correttamente ritornati solo 
alcuni record.
Quindi le stored procedure in questione funzionano tranquillamente.
Dove sta il problema?
Se l'origine riga di una combo è una stored procedure parametrica, il parametro 
per caso non può fare riferimento ad un altro controllo della form stessa?
Spero proprio che possiate aiutarmi.
Grazie.
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype: pbsoftsolution

"PBsoft" <in...@REMOVEpbsoft.it> ha scritto nel messaggio
news:875ea355361728...@news.tin.it...

Ciao Gabriele,
questo modo di impostare l'origine dati della combo non l'ho mai usato e non
so se è "ammissibile"  (Giorgio ci dirà sicuramente qualcosa)
Hai provato con il Profiler a vedere che istruzione viene inviata a SQL
Server? questo potrebbe essere d'aiuto per capire il problema.
Io di solito quando devo impostare delle combo passando parametri presi da
altri controlli della maschera uso combo Non associate e sull'evento enter
della combo  creo il recordset e lo assegno allo proprietà recordset della
combio stessa nel tuo caso potrebbe essere una cosa di questo tipo:
Versione breve:
Set me.tuaCombo2.recordset = currentProject.connection.tuaStored
[Forms]![nomedellaform]![combo1]
Versione lunga:
Dim cmd as new Adodb.command
cmd.activeConnection = CurrentProject.connection
cmd.commandtext = "NomeStored"
cmd.commandType= acCmdStoredProc
set me.tuaCombo2.Recordset= cmd.execute(,
[Forms]![nomedellaform]![combo1])
set cmd = nothing
Ciao
-- 
Cinzia
---------------------------------------
|  
http://www.riolab.org
  |
--------------------------------------- 

 set cmd = nothing
La tua soluzione è carina e sicuramente funzionante. Volevo solamente evitare 
di passare per il codice (anche se poi non l'ho evitato) cercando un metodo 
che fosse simile al funzionamento della proprietà InputParameters delle Form 
basate su stored procedure.
Grazie per le tue osservazioni.
