Newsgroup: it.comp.appl.access
Titolo: Evento load non eseguito

Ciao a tutti,
lavoro con access XP (!?!).
 
Apro un form (da MSC_AVVIO) con la seguente chiamata:
DoCmd.OpenForm "MSC_CLIENTI", , , , , acDialog
 
Nell'evento load di MSC_CLIENTI assegno il valore in questo modo:
Me.RecordSource = QRY
+ altre operazioni
Il valore QRY viene passato tramite una variabile globale.
 
In alcuni pc l'evento load non viene eseguito.
Ho notato che quando ciò non avviene la variabile QRY contiene valori "raccolti" tramite due controlli MSCAL.Calendar.7.
In tutti gli altri casi funziona correttemente.
Ho anche vericato che QRY venga valorizzato correttamente (e così è) prima dell'apertura del form.
 
Qualche idea?

Aggiornamento.
Se metto il codice nell'evento open del form mi ritrovo questo errore:
 
errore n° 3146
ODBC: chiamata non riuscita
[Microsoft][ODBC SQL Server Driver][SQL Server] Conversione non riuscita durante la conversione di una stringa di caratteri in una data o ora. (à241)
 
La query è la seguente:
 
SELECT P.* FROM CLIENTI C INNER JOIN POLIZZE P ON C.ID_CLIENTE = P.ID_CLIENTE
WHERE  P.SCADENZA_COPERTURA>=#7/1/17# AND P.SCADENZA_COPERTURA<=#7/31/17#
ORDER BY C.RAGIONESOCIALE, P.SCADENZA DESC
 
 
 
Su windows 7 pro in italiano con access 2002 funziona senza problemi
Su windows 7 pro in inglese con access run time 2007 l'errore di cui sopra
 
Idee?


Ma hai MsSQL come DBServer...?
Se fosse così attento alle date... non hanno la sintassi corretta, quella è per JET
 
@Alex


Aggiornamento.
 
Analizzando con SQL Profiler a fronte della stessa query:
SELECT P.* FROM CLIENTI C INNER JOIN POLIZZE P ON C.ID_CLIENTE = P.ID_CLIENTE
WHERE  P.SCADENZA_COPERTURA>=#7/1/17# AND P.SCADENZA_COPERTURA<=#7/31/17#
ORDER BY C.RAGIONESOCIALE, P.SCADENZA DESC
 
 
Da windows 7 pro in italiano con access 2002:
SELECT "C"."ID_CLIENTE","P"."ID_POLIZZA"
FROM "dbo"."POLIZZE" "P","dbo"."CLIENTI" "C"
WHERE ((("P"."SCADENZA_COPERTURA" >= {d '2017-07-01'} ) AND ("P"."SCADENZA_COPERTURA" <= {d '2017-07-31'} ) ) AND ("C"."ID_CLIENTE" = "P"."ID_CLIENTE" ) )
ORDER BY "C"."RAGIONESOCIALE" ,"P"."SCADENZA"  DESC 
 
 
Da windows 7 pro in inglese con access runtime 2007 (italiano):
SELECT "C"."ID_CLIENTE","P"."ID_POLIZZA"
FROM "dbo"."POLIZZE" "P","dbo"."CLIENTI" "C"
WHERE ((("P"."SCADENZA_COPERTURA" >= {ts '01/07/2017'} ) AND ("P"."SCADENZA_COPERTURA" <= {ts '31/07/2017'} ) ) AND ("C"."ID_CLIENTE" = "P"."ID_CLIENTE" ) )
ORDER BY "C"."RAGIONESOCIALE" ,"P"."SCADENZA"  DESC 
 
Come se ne esce?

Il giorno mercoledì 5 luglio 2017 20:17:07 UTC+2, Roberto ha scritto:

Prova a impostare la query in questo modo :
 SELECT P.* FROM CLIENTI C INNER JOIN POLIZZE P ON C.ID_CLIENTE = P.ID_CLIENTE
 WHERE  P.SCADENZA_COPERTURA>=datevalue("1 luglio 2017") AND P.SCADENZA_COPERTURA<= datevalue("31 luglio 2017")
 
Di solito in questo modo evito problemi di gestione date,
non so se peggiora le prestazioni della query
 
Gabry



grazie mille, così funziona in entrambi gli ambienti
per le prestazioni vediamo

al di là della soluzione resta senza risposta la domanda iniziale.
perché due comportamenti diversi se la query che viene inviata è uguale?

 perché due comportamenti diversi se la query che viene inviata è uguale?
 
Italiano ed Inglese... sono impostazioni Imternazionali del Sistema Operativo che hanno effetto sul driver del DB SERVER.
Prova ad usare Query Parametriche passando il Parametro... nessuno lo fa ma...
 
@Alex

 @Alex
 
Scusa ma non ho capito.
Cosa dovrebbe succedere con una query parametrica?


Quando io parlo di query Parametricha intendo la definizione scolastica di query Parametrica... quindi quella con la Definzione esplicita dei PARAMETERS in calce e di conseguenza li si utilizza da codice per valorizzarli.
Questa è una distinzione che pochi fanno sbagliando alla grande.
Tu cosa intendi quando mi fai la domanda...?
Perchè se intendi quello che intendo io, dovresti anche sapere che un conto è passare un PARAMETRO un conto è farl leggere alla Query un riferimento... 
 
Quindi, prova a definire come parametri le DateCardine e passali usando il metodo corretto, poi vedi quale sintassi è corretta e come viene interpretata dal profiler...
 
QUERY [QTEST]SQL:
PARAMETERS [BeginningDate] DateTime;
SELECT * FROM T1
 WHERE CampoData=[BeginningDate];
 
Ora da VBA apri una 
Set qdf=QueryDefs("QTEST")
qdf.Parameters![BeginningDate]=TuaData(Verifica che formattazione serve)
Set rs = qdf.OpenRecordset
 
Ovviamente stessi vantaggi per Testo, non servono APICETTI, NUMERI non serve il riconoscimento Impostazioni Internazionali [.,] ecc...
 
@Alex

Ho provato le query parametriche.
Il profiler crea un evento RPC.
Pare che tramite vba sia più performante ma non ho certezza.
In questo modo non fa confusione con le date ma non sono sicuro che sia meglio.


Rassicurati.
 
@Alex

Grazie per le dritte.
 
Approfitto per chiederti un'altra questione.
Uso il profiler per capire come 'lavorano' le query. Ma non sono sicuro di leggere bene i dati.
Hai qualche consiglio su cosa monitorare.
Prevalentemente leggo il tempo di risposta ma sicuramente ci sono altri parametri da tenere presente.


Ormai sono 10 anni che non faccio più nulla di serio, quindi fatico a darti suggerimenti aggiornati.
Ricordo che l'analizzatore delle Query consentiva di vedere anche i PIANI DI ESECUZIONE, ovvero lo SHOWPLAN, che rendeva l'idea di come il predicato veniva intepretato, eseguito e risolto... 
Ad esempio i CRITERI WHERE,Concatenare a livello LOGICO BOOLEANO 2 Criteri, è differente in termini di esecuzione usare 
(C1 AND C2) o un
NOT C1 OR NOT C2
ha la sua differenza...
Lavorando poi con Access, dovresti anche capire se, il Numero di Records restituiti a JET è veramente quello che la condizione o il JOIN definiscono... perchè se ad esempio passi un Predicato non risolvibile da SQL è evidente che viene restituita tutta la Tabella e delegato JET in locale...
Alcuni esempi semplici:
SELECT * FROM T1 WHERE ID=FORMS!MASCHERA!Controllo
SELECT *, functCalcolo([CampoData]) As RetCalcolo FROM T1
SELECT *, DCOUNT(....) FROM T1...
 
In nessuno dei 3 casi il Server riesce a risolvere il predicato, quindi semplifica la sua vita e restituisce TUTTA T1... poi JET in locale applica il Criterio ID risolvendo FORMS!Maschera!Controllo o la Funzione functCalcola o la DCOUNT()...
 
Non so se questo aggiunge qualche cosa...:
https://technet.microsoft.com/it-it/library/ms177500(v=sql.105).aspx
 
 
@Alex

 
https://technet.microsoft.com/it-it/library/ms177500(v=sql.105).aspx
 
 
Aggiunge, aggiunge.
Studio un po' e poi magari chiedo.
Nel frattempo grazie mille