Oggetto Querydef non aggiornabile se transazione attiva con maschera continua

Phil complimenti per la tenacia ... ho provato il tuo approccio e 'tristemente' funziona !
Certo rimango spiazzato da certi comportamenti, in fondo io avevo anche provato con la forza bruta (cancellare e ricreare la query tramite workspace) con esito negativo ...
Vabbè, che dire : "tutto è bene quel che finisce bene e l'ultimo chiuda la porta"

Originariamente inviato da Max.Riservo

...Certo rimango spiazzato da certi comportamenti, in fondo io avevo anche provato con la forza bruta (cancellare e ricreare la query tramite workspace) con esito negativo ...

Spiazzato? mah... guarda... forse ti sei fatto prendere dalla frustrazione dei tentativi (a me accade questo, quando si passa troppo tempo su un problema) e non hai considerato la "soluzione più semplice".
La strada di aprire un workspace diverso era quella giusta, non so perché però ti sei lanciato sulla cancellazione della query quando bastava modificarla.
Prima sono partito dai tuoi tentativi, per vedere se ottenevo gli stessi errori, perché è il modo che ritengo più affidabile per dire di aver ricostruito la situazione quanto più simile a quella reale.
Anch'io con il sistema della cancellazione della query e ricostruzione (il sistema "forza bruta") non ne uscivo, con refresh di QueryDefs prima, dopo, durante eccetera.
Il sistema più lineare era quello giusto: modificare (e basta) la SQL come facevi già, ma non partendo da CurrentDb, che per definizione appartiene al Workspace(0) sul quale era in corso la transazione, ma da un altro workspace, come stavi facendo i tentativi "forza bruta".
Tutto è bene quel che finisce bene e mi fa star bene se do una mano.

Originariamente inviato da Phil_cattivocarattere

Spiazzato? mah... guarda... forse ti sei fatto prendere dalla frustrazione dei tentativi (a me accade questo, quando si passa troppo tempo su un problema) e non hai considerato la "soluzione più semplice".

Vero ... purtroppo

Originariamente inviato da Phil_cattivocarattere

La strada di aprire un workspace diverso era quella giusta, non so perché però ti sei lanciato sulla cancellazione della query quando bastava modificarla.

Semplice : la modifica con currentdb falliva, quindi ho pensato che fosse necessario usare un metodo più 'violento'.
Resta lo stupore di fondo : la modifica funziona, la cancellazione+inserimento NO.

Comunque : "Dice il saggio : tutto è bene quel che finisce bene" ... "Ebbene sì maledetto Access ! Hai vinto anche stavolta !"

Originariamente inviato da Max.Riservo

Resta lo stupore di fondo : la modifica funziona, la cancellazione+inserimento NO.

Ah, a questo è dovuto lo stupore? Sento odore di sfida nell'aria. Contro Access, intendo. E a questo tipo di odore e di sfida mi gusta molto.

La cosa mi aveva incuriosito... ed ho fatto vari tentativi... ma sono giunto ad una conclusione logica, non so quanto possa esserlo ma non avrei nemmeno altri ragionamenti da porre.

Premesso che non ho trovato NULLA nel WEB che trattasse di Editing della proprietà SQL di QueryDef WHILE TRANSACTIONS...

Ho provato anche a Cancellarla e ricrearla, la Query, ma mentre mi consente di Cancellarla, non mi consente di Crearla durante la transazione... quindi deve esserci un LEGAME stretto tra il WorkSpace in cui si è attivata la transazione e gli Oggetti del DB, possibili destinatari della transazione.

Nella sostanza aprendo la transazione vengono bloccate, almeno sembra, le proprietà che possono interagire con la transazione, peraltro provate a pensare a cosa potrebbe rispristinare un RollBack dell Transazione se si cambiassero i predicati SQL... più e più volte.
Uno potrebbe dire, ma che importa su una Query SELECT...? Beh... vero ma il ragionamento sarebbe poco utile... dal momento che una QUERY SELECT potrebbe essere quota parte di una Query ACTION...

Questo ragionamento viene avallato proprio dal fatto che per farlo funzionare si è dovuto creare un WS esterno in cui non è attiva la Transazione...

Aggiungerei il CLOSE del WorkSpace... a titolo di pignoleria.

Riassumendo non è pulito ma non saprei cos'altro aggiungere.

Originariamente inviato da Max.Riservo

Comunque : "Dice il saggio : tutto è bene quel che finisce bene" ... "Ebbene sì maledetto Access ! Hai vinto anche stavolta !"

Aggiunge il Phil: perché quello che NON funzionava domenica adesso funziona?
Siccome tirava aria di sfida, ho provato a tornare indietro. E non ci riesco, non riesco ad andare "in errore".

On Error Resume Next
If IsNull(Me.cmbTabelle.Value) Then Exit Sub
Dim strTabella As String
strTabella = Me.cmbTabelle.Value
Dim strSQL As String
strSQL = "SELECT * FROM [" & strTabella & "]" 'perché fa comodo con altre prove, senza riscrivere tutto

Dim wrkAcc      As DAO.Workspace
Dim dbs         As DAO.Database
             
' Create a new Microsoft Access workspace.
Set wrkAcc = DBEngine.CreateWorkspace("ANCF_Wrk", "admin", "", dbUseJet)
Set dbs = wrkAcc.OpenDatabase(DBEngine.Workspaces(0).Databases(0).Name)
dbs.QueryDefs.Delete ("DummyExportQuery")
Application.RefreshDatabaseWindow
On Error GoTo 0
dbs.QueryDefs.Refresh
dbs.CreateQueryDef "DummyExportQuery", strSQL

Me.SM_Continuous.SourceObject = "Query.DummyExportQuery"

Set dbs = Nothing
Set wrkAcc = Nothing

Ad eccezione dell'uso di una variabile per la SQL (solo perché facendo le varie prove è molto più semplice avere quella stringa in una variabile facile da digitare) è esattamente il codice che aveva già pubblicato (e prima provato) Max.Riservo. Adesso funziona. Domenica no.
L'unica cosa che potrei pensare di questa "assenza di problemi" (notare che sto scrivendo perché non riesco ad avere problemi!) è che se in una fase di prova va in errore e non si chiude Access anche dal task manager (perché anche se sembra chiudersi in realtà rimane là sotto a lavorare, a volte) anche le successive prove, apparentemente fatte in una situazione nuova e pulita sono influenzate da quell'istanza di MsAccess che gira sotto. Ed ovviamente adesso non riesco ad avere questa situazione, perché anche se con qualche errore più o meno intenzionale Access si chiude a dovere.

Aggiungo, per la cronaca:

If IsNull(Me.cmbTabelle.Value) Then Exit Sub

Dim strTabella As String
strTabella = Me.cmbTabelle.Value
Dim strSQL As String
strSQL = "SELECT * FROM [" & strTabella & "]"
CurrentProject.Connection.Execute "DROP Table DummyExportQuery"
CurrentProject.Connection.Execute "CREATE View DummyExportQuery AS " & strSQL

senza bisogno di aprire un workspace ad hoc diverso da quello sul quale c'è la transazione aperta.
Ok, non è certo il modo migliore di agire su un file accdb, però funzia.

Originariamente inviato da Phil_cattivocarattere

Siccome tirava aria di sfida, ho provato a tornare indietro. E non ci riesco, non riesco ad andare "in errore".

Mi consola ... ho trigato 2 sere per individuare il problema e per trovare una via d'uscita
Penso che siamo in una zona 'borderline' di Access, almeno io lo sono di sicuro : Access con ODBC (driver mySQL e non MariaDB) e MariaDB.
Da quando mi sono imbarcato in quest'avventura di rifacimento in chiave più aggiornata (front end) e più affidabile (back end) di un grosso applicativo in A2k mi sono scontrato con diverse stranezze, fortunatamente risolte/bypassate, che comunque mi hanno fatto penare (e pensare in alcuni momenti di sconforto di abbandonare tutto) e perdere non poco tempo.

Originariamente inviato da Max.Riservo

ho trigato 2 sere per individuare il problema e per trovare una via d'uscita

Tu hai trigato 2 sere per trovare una via d'uscita? Hai trigato 2 sere per cercare la via d'uscita, non per trovarla. Ehm... quanto siamo suscettibili eh? il sottotrattoeccetera dopo Phil non è lì per essere originale nel nick. (si scherza, ovviamente)

Originariamente inviato da Max.Riservo

Penso che siamo in una zona 'borderline'

Voglio entrare anch'io in zona borderline più di quanto lo sia già. Mi spiegheresti questa per favore?

Originariamente inviato da Max.Riservo

ODBC (driver mySQL e non MariaDB) e MariaDB

Dove è MariaDB? Dove è mySQL?
Il server BE è MariaDB ma il driver ODBC per il collegamento è quello di mySQL? ho capito bene? E' ora di installare qualcosa sul mio computer... che bello!!!

Originariamente inviato da Phil_cattivocarattere

Dove è MariaDB? Dove è mySQL?
Il server BE è MariaDB ma il driver ODBC per il collegamento è quello di mySQL? ho capito bene? E' ora di installare qualcosa sul mio computer... che bello!!!

Cominciamo dall'origine :
- tutti i miei PC, quelli in ditta e alcuni presso Clienti (a loro insaputa ) usano nativamente Linux (openSUSE)
- siccome nel mondo Linux sono fissati con le Licenze e con i limiti imposti da esse, alcuni anni fa hanno rimpiazzato mySQL con MariaDB (che è un suo fork)
- io, se non ci sono esigenze particolari, cerco di restare su quanto offerto dalla distribuzione che uso (openSUSE). MariaDB è ampiamente sufficiente per le mie esigenze così da non dovermi costringere ad utilizzare repository di terze parti (evito anche di dover magari ricompilare i sorgenti)
- per accedere al DB direttamente da openSUSE utilizzo phpMyAdmin che mi permette una discreta operatività. Oggettivamente il QBE di Access è comunque più potente (come 'side effect' l'inferiorità di phpMyAdmin costringe magari ad imparare meglio la sintassi SQL)
- utilizzo MS solo in macchine virtuali e finalmente da inizio anno mi sono anche liberato delle rogne di VMware (con il mondo Linux) passando definitivamente ad un virtualizzatore Linux nativo.
- la macchina virtuale con Access utilizza i driver ODBC per accedere al DB. La scelta naturale sarebbe utilizzare i driver ODBC MariaDB : li ho provati, funzionano ma hanno alcune pecche, una su tutte non permettono di avere in una unica chiamata al DB l'esecuzione di una query di inserimento con restituzione del Last_Insert_ID. Questa 'feature' la ottieni invece con i driver ODBC MySQL (e utilizzando lato Access il NextRecordset). Il confronto tra i 2 driver (e tra versioni diverse di driver) l'ho fatto tempo fa quindi, non avendo sottomano la macchina di sviluppo, non sono in grado di elencare altri pregi/difetti. Per onestà, la non possibilità dei driver MariaDB di ottenere nella stessa chiamata il Last_Insert_ID , non è così invalidante in quanto il Last_Insert_ID è gestito a livello di connessione quindi anche una successiva "Select Last_Insert_ID From Tabella" restituisce sempre il valore corretto

Serve altro ?

Originariamente inviato da Phil_cattivocarattere

Tu hai trigato 2 sere per trovare una via d'uscita? Hai trigato 2 sere per cercare la via d'uscita, non per trovarla. Ehm... quanto siamo suscettibili eh? il sottotrattoeccetera dopo Phil non è lì per essere originale nel nick. (si scherza, ovviamente)

Comunque la via d'uscita l'ho trovata dopo averla cercata 2 sere : tre pulsanti, tre query, aggiornate prima di avviare la transazione, poco elegante ma funzionale ...