[VBA] Aiuto per esecuzione query

[tomino87]

Ho un progetto adp su access 2003, che si collega as un database su SQL server 2005 e volevo fare una piccola prova con una query INSERT su una tabella di prova.
Ho creato un piccolo form, che consta di un solo bottone, al quale è associata la seguente sub per l'evento click:

Private Sub Comando0_Click()
    Dim db As DAO.Database
    Dim sql As String
    
    Set db = CurrentDb
    sql = "INSERT INTO prova_insert (date,id) VALUES ('19/05/2009',2)"
    db.Execute sql
    Set db = Nothing
End Sub

Quando testo il form, cliccando il bottone, mi viene mostrato il messaggio di errore:

"Errore di run-time '91': Variabile oggetto o variabile del blocco With non impostata"

Ora... guardando un pò in giro per il/i forums ho capito che ciò succede quando si cerca di assegnare un valore o utilizzare una variabile che non ha una buona referenza... in particolare a me l'errore me lo da all' istruzione "execute": però io ho dichiarato db e ho anche settato db = CurrentDb... quindi perchè mi viene mostrato sto picchio di errore???

Grazie in anticipo per chiunque voglia aiutarmi...

Piero

[MarcoGG]

Originariamente inviato da tomino87

Private Sub Comando0_Click()
    Dim db As DAO.Database
    Dim sql As String
    
    Set db = CurrentDb
    sql = "INSERT INTO prova_insert (date,id) VALUES ('19/05/2009',2)"
    db.Execute sql
    Set db = Nothing
End Sub

C'è decisamente troppo codice per quello che devi fare.
Nel tuo caso specifico non so perchè dia errore, ma puoi risolvere drasticamente con :

1. Se vuoi concatenare :

DoCmd.RunSql "INSERT INTO prova_insert ( date, id ) VALUES ( #19/05/2009#, 2 )"

> Meglio usare i caratterri sharp " # " per delimitare le date, in quanto gli apici possono dare problemi...

2. Se, meglio ancora, vuoi usare i parametri, vedi mio esempio qui :
http://www.hwupgrade.it/forum/showthread.php?t=1977950

[tomino87]

Innanzitutto grazie per la risposta

Riguardo agli sharp # per i valori.... non vanno bene per SQL Server...
Access nelle query accetta i valori delimitati da #, ma SQL Server non li accetta... e l'unico modo per inserire/far confronti/lavorare con le date nelle query in SQL Server è con gli apici singoli....

Riguardo al codice che mi hai scritto, funziona

Solo una curiosità: siccome non sono esperto di vba.... perchè quella che mi hai detto sarebbe una soluzione "drastica"?

[MarcoGG]

Originariamente inviato da tomino87

Innanzitutto grazie per la risposta
Riguardo agli sharp # per i valori.... non vanno bene per SQL Server...
Access nelle query accetta i valori delimitati da #, ma SQL Server non li accetta... e l'unico modo per inserire/far confronti/lavorare con le date nelle query in SQL Server è con gli apici singoli....

Sì, mi ero perso la prima parte in cui parlavi di Sql Server...
Ma quel "CurrentDb" funziona con Sql Server, poi ?
Cioè, non mi era chiaro se quel codice VBA esegue una Insert in Access o in Sql Server... o in tutti e due...

Originariamente inviato da tomino87

Riguardo al codice che mi hai scritto, funziona

Solo una curiosità: siccome non sono esperto di vba.... perchè quella che mi hai detto sarebbe una soluzione "drastica"?

"Drastica" nel senso che gli errori 91 < Variabile oggetto o variabile del blocco With non impostata > sono spesso dovuti all'utilizzo di librerie non referenziate, o all'uso di oggetti a nothing, ossia prima che siano stati inizializzati. Non ho provato il tuo codice, perchè appena ho visto che tentavi di fare una semplice Insert, ho suggerito DoCmd, che appunto è la strada più diretta in assoluto ( ma che può riservare brutte sorprese, a differenza della tecnica con parametri, più lunga, ma più sicura... ), se parliamo di Access-VBA.
Quindi DoCmd è una delle funzioni VBA di base, non necessita riferimenti ad ADODB, DAO o altre librerie, e perciò virtualmente immune agli errori 91.

[tomino87]

Ahh ora è tutto chiaro... cmq l'insert era su sql server: in realtà tutte le operazioni vengono fatte su sql server... questa era semplicemente una prova per trovare del codice che funzionasse per eseguire query di comando sul database su sql server che sarà collegato al mio progetto adp.
Il progetto è un progetto mooolto serio... per questo forse la strada del DoCmd non è molto appropriata (in quanto mi hai detto che può riservare sorprese...)

Ho fatto per conto mio un paio di "prove"... e pensavo di utilizzare codice di questo tipo (visto che praticamente tutto il progetto su cui sto lavorando utilizza la libreria ADODB):

Dim rst As ADODB.Recordset
Set rst = New ADODB.Recordset
rst.Connection = CurrentProject.Connection

Dim sqlstr As String
sqlstr = "Stringa sql da inviare al server"

rst.Open sqlstr, CurrentProject.Connection

(naturalmente con un opportuno "On Error GoTo ..." prima del "rst.Open ...", in modo da captare possibili errori sull' esecuzione della query)

Secondo te può essere meglio agire così? Oppure sono solo dei problemi mentali che mi sto facendo?

[MarcoGG]

Originariamente inviato da tomino87

Il progetto è un progetto mooolto serio... per questo forse la strada del DoCmd non è molto appropriata (in quanto mi hai detto che può riservare sorprese...)

No, infatti. DoCmd può essere un'ottima scorciatoia, a patto che si sappia esattamente come gestire la concatenazione tra istruzioni Sql e valori, e comunque ti espone a problemi. Piccolo esempio classico :

    Dim stringa As String
    stringa = "questa non crea problemi"
    DoCmd.RunSQL "INSERT INTO nomeTabella (id, campoStringa) VALUES (100, " & "'" & stringa & "'" & ")"

    Dim stringa As String
    stringa = "Questa crea un po' di problemi"
    DoCmd.RunSQL "INSERT INTO nomeTabella (id, campoStringa) VALUES (100, " & "'" & stringa & "'" & ")"

mentre al link che ti ho dato trovi proprio un esempio di come usare gli ADODB Parameters...

Originariamente inviato da tomino87

Ho fatto per conto mio un paio di "prove"... e pensavo di utilizzare codice di questo tipo (visto che praticamente tutto il progetto su cui sto lavorando utilizza la libreria ADODB):

Dim rst As ADODB.Recordset
Set rst = New ADODB.Recordset
rst.Connection = CurrentProject.Connection

Dim sqlstr As String
sqlstr = "Stringa sql da inviare al server"

rst.Open sqlstr, CurrentProject.Connection

(naturalmente con un opportuno "On Error GoTo ..." prima del "rst.Open ...", in modo da captare possibili errori sull' esecuzione della query)

Secondo te può essere meglio agire così? Oppure sono solo dei problemi mentali che mi sto facendo?

Su questo non mi posso pronunciare al momento, dato che non ho mai sperimentato una cosa simile, ossia un progetto Access che tramite VBA faccia operazioni su Sql Server, ( ho invece spesso usato Excel VBA, VB6 o VB.NET... ) perciò mi suona molto strano che con quella CurrentProject.Connection tu riesca a combinare qualcosa... Il mio consiglio è di usare le tecniche standard ADODB ( che sono le medesime che useresti da un'applicazione VB6 ), senza "mischiarle" con tecniche tipicamente Access, come CurrentProject / CurrentDB / DoCmd ecc...
In ogni caso prova... E fammi sapere.

[tomino87]

Dunque... ho letto il post che mi hai indicato. E' un procedimento molto interessante. Però ho un'osservazione da fare: tu mi hai detto di non usare CurrentProject.Connection, visto che mi collego ad sql server...

In realtà non mi sembra un'eresia indicare come connessione la CurrentConnection anche nel mio caso, in quanto sto lavorando con un adp che è collegato al database sul server sql... ovvero, nelle proprietà del progetto, la fonte dati è un database su uno specifico server sql: pertanto logicamente la CurrentProject.Connection dovrebbe restituire la connessione al detto server sql. Correggimi se sbaglio (o eventualmente esprimimi meglio il tuo dubbio )...

p.s.: la soluzione con CurrentProject.Connection che ho indicato l'ho testata e funziona...

[MarcoGG]

Originariamente inviato da tomino87

Dunque... ho letto il post che mi hai indicato. E' un procedimento molto interessante. Però ho un'osservazione da fare: tu mi hai detto di non usare CurrentProject.Connection, visto che mi collego ad sql server...

In realtà non mi sembra un'eresia indicare come connessione la CurrentConnection anche nel mio caso, in quanto sto lavorando con un adp che è collegato al database sul server sql... ovvero, nelle proprietà del progetto, la fonte dati è un database su uno specifico server sql: pertanto logicamente la CurrentProject.Connection dovrebbe restituire la connessione al detto server sql. Correggimi se sbaglio (o eventualmente esprimimi meglio il tuo dubbio )...

p.s.: la soluzione con CurrentProject.Connection che ho indicato l'ho testata e funziona...

Io ti ho suggerito di non mischiare, preferibilmente, il VBA tipico di Access ( fatto di comandi-scorciatoia che non non trovi ad esempio in Excel-VBA o VB6 ) con le tecniche ADODB, che invece puoi usare indifferentemente da qualsiasi implementazione Office di VBA o da VB6, per un mero discorso di omogeneità. Era un consiglio di ciò che farei io, tutto qui. Se poi in futuro dovessi riutilizzare quel codice da Excel-VBA, o da VB6 o da altri applicativi che fanno uso di VBA ( Corel ecc... ) ti troveresti spiazzato, perchè non avresti più a disposizione i vari DoCmd, CurrentDb ecc...

Non avendo una gran esperienza con i progetti ADP di Access ( per il semplice motivo che, per scelta personale, evito accuratamente di creare applicativi 100%-Access ) ti avevo messo in guardia dall'usare CurrentProject.Connection, ma se dici che è tutto ok, per me va bene.

[tomino87]

Mi trovi del tutto daccordo sul non utilizzare soluzioni al 100% access... a dir la verità io non lo farei nemmeno all' 1%

Il punto è che il progetto su cui lavoro non è una cosa che faccio io da capo: si tratta di un upsizing di un db molto grosso con un sistema informativo (come avrai capito in vba..) da access a sql...
Quindi devo modificare tutto il codice vba (che precedentemente era pensato per funzionare con access) in modo che si interfacci correttamente col db, che d'ora in poi starà su sql server...
Naturalmente non è che posso buttare via tutto Devo quindi tenermi questa scelta iniziale (che non ho fatto io) di utilizzare in grossa parte l'ambiente access.... questo il motivo per cui ho creato l'adp, che a detta di tutti (anche della stessa microsoft) è la soluzione migliore per i progetti access che utilizzano come fonte di dati non access stesso, bensì sql server