Differenze gestione query

Introduzione

I driver di database .NET e Java impongono alcune limitazioni aggiuntive nell'esecuzione delle query. Quando un'applicazione scritta in Visual Basic viene compilata in tecnologia C# o Java occorre tenere presente queste limitazioni e, dove richiesto, apportare i necessari adattamenti. Di seguito sono elencate i casi più rilevanti:

C#/Java: Limitazione nel numero di tabelle utilizzate nelle query scrivibili

L'oggetto Recordset di Visual Basic 6 permetteva di modificare i dati provenienti da una query contenente più di una tabella. I drivers .NET e JDBC, invece, non permettono di modificare direttamente i dati provenienti da una query contenente più di una tabella in join nella from list. Per esempio, se la master query di un pannello contiene una inner join tra due tabelle, quando si tenta di salvare i dati a si ottiene in C# il seguente messaggio di errore:

Dynamic SQL generation is not supported against multiple base tables.

e in Java il seguente messaggio di errore:

[Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Invalid column name 'XXX'

dove 'XXX' indica il nome di una delle colonne della query (questo nonostante la query sia corretta e il nome della colonna sia corretto).

Nota: utilizzando la tecnologia Java può succedere che il driver JDBC sia in grado di modificare i dati di una query con più tabelle. Può anche capitare che le modifiche su alcune colonne non generino l'errore mentre modifiche su altre colonne della stessa query generino l'errore.

Workaround

• La soluzione consiste nell'utilizzare una View (a sua volta definita come join tra più tabelle) come master query dei pannelli scrivibili contenenti più tabelle. La limitazione, infatti, è imposta dal driver che non riesce a calcolare le corrette query di insert/update/delete partendo da una query complessa, contenente più tabelle. Utilizzando una vista il driver è in grado di calcolare le query necessarie alle modifiche. E' poi compito del database gestire le scritture sulla vista effettuando le operazioni sulle tabelle reali.

C#/Java: Rilettura dei records modificati dopo il salvataggio dei dati

Il driver ADO per il linguaggio Visual Basic possedeva un'interessante funzionalità: la rilettura di un record appena modificato. Per capire a fondo il vantaggio di questa funzionalità si immagini di avere una query di un pannello che restituisca 1000 records. Quando l'utente modifica, per esempio, il record 100 e preme il dischetto di salvataggio il framework IN:DE comunica la modifica al driver ADO che a sua volta decide di eseguire uno statement di update per la sola riga modificata. L'oggetto Recordset (del driver ADO per Visual Basic) possedeva un metodo chiamato "Resync" che chiedeva al driver di rileggere tutti i campi delle sole righe modificate. Questo poteva essere utile nel caso un trigger su database avesse "completato" la modifica al record stesso modificando altri campi della stessa riga. Solo chiamando il metodo "Resync" era possibile ri-aggiornare i dati contenuti nel pannello senza dover rieseguire tutta la query (che rileggerebbe tutti i 1000 records).

Workaround
Il tipo di workaround necessario per aggirare la limitazione dipende dal numero medio di records contenuti in un pannello:

• se il numero di records normalmente restituiti da un pannello non è eccessivo è sufficiente aggiungere il comando RefreshQuery nell'evento AfterCommit del pannello (tale evento, come descritto nella documentazione, viene notificato una volta che il pannello ha completato tutte le operazioni di scrittura sul database). In questo modo, quando i dati di un pannello vengono salvati, viene rieseguita la query ed i dati risultano aggiornati.
• se il numero di records restituiti da un pannello può essere consistente suggeriamo un altro metodo: "replicare" la logica descritta nel trigger all'interno dell'applicazione Client. In altre parole è sufficiente implementare l'evento AfterUpdate del pannello (tale evento, come descritto nella relativa documentazione, viene notificato per ogni record modificato subito dopo aver eseguito l'operazione di aggiornamento dello stesso sul database) e in tale evento eseguire le stesse operazioni che vengono eseguite dal trigger. In questo modo i dati disponibili nel pannello saranno gli stessi presenti su database, senza aver avuto la necessità di ri-sincronizzarli.