delphi7+Firebird---->delphix3+Firebird IBTable

[123delphi321]

delphi7+Firebird---->delphix3+Firebird

Ciao a tutti,

ho avuto modo di testare una mia procedura, scritta con delphi 7, aprendola con delphi x3.

al di la di qualche semplice modifica sembrava andare tutto bene...

il problema che mi ha bloccato è nell'utilizzo del componente IBTable, che per quanto trovato nei vari post su internet sembra essere un componente obsoleto!

a questo punto devo sostituire l'utilizzo di IBTable con IBDataset o IBQuery.

forse, però, io sbaglio qualcosa di come utilizzo IbTable in delphi7.

l'IBTable lo utilizzo principalmente per recuperare i dati di lookup...faccio un esempio:

in una procedura di fatturazione ho questa situazione:

IBDatasetClienti,IBtableClienti
IBDatasetOrdini

nella form che gestisce la tabella clienti opero su IBDatasetClienti
nella form che gestisce la tabella Ordini opero su IBDatasetOrdini ed apro IBTableClienti per recuperare i dati di lookup.

questa tecnica fa si che per ogni tabella anagrafica (del database della mia procedura), ho un IBDataset e una IBTable associati alla stessa tabella del database.

funzione...ma mi domando se forse Voi utilizzate un approccio migliore per l'utilizzo del lookup.

grazie

[franzauker2.0]

Personalmente uso ZEOS (per mysql) e mydac (per mariadb); in generale utilizzo tutte query "slegate", ma nel tuo esempio ne utilizzo di temporanee (oneshot) con le quali prendo i risultati (temporanei) che mi interessano.
Sono tutti "cugini" di tquery

[123delphi321]

ciao,

quindi non sbaglio ad associare una tibquery per ogni tabella!?...

grazie

[franzauker2.0]

Francamente non mi è chiaro perchè dovresti "sbagliare", dipende essenzialmente dall'esistenza di componenti visuali con relativi tdatasource.
In questo caso servono tanti tdatasource diversi quanti componenti hai, e ogni tdatasource lo devi legare a un "qualcosa" (query o table).

Il rovescio della medaglia riguarda l'avere molti componenti (ma questo in generale non è un problema, lo era con Win95 e le risorse parzialmente a 16 bit), ma soprattutto il rischio che un disablecontrols, per motivi strani, non funzioni come ti aspetteresti (=> rallentamento per refresh multiplo).

Per attività tipo contare quante righe ci sono in una certa tabella, verificare se un record è già presente etc, ovvero quelle attività che sono tipicamente "oneshot", uso una t(qualcosa)query definita, tra l'altro, in una form sempre esistente (quella del login), cosicchè non la devo creare-freeare ogni volta.

Cosa ti turba? Te lo chiedo perchè mi sembra che ti stai ponendo un problema... senza porti il problema del perchè te lo poni

[123delphi321]

ciao,

mi ponevo il problema in quanto, forse, Voi utilizzavate un metodo più semplice/pratico per i campi lookup.

adesso, anche se ancora non utilizzo xe3, farò in modo di non utilizzare componenti in qualche modo obsoleti.

nelle mie procedure, utilizzo il datamodule con dentro tutti i dataset, query,..etc in modo che questi sioano visibili da ogni form della stessa procedura.

a questo punto, va bene cosi....creo un datasource per ogni tabella di lookup.

grazie

[franzauker2.0]

Originariamente inviato da 123delphi321
nelle mie procedure, utilizzo il datamodule con dentro tutti i dataset, query,..etc in modo che questi sioano visibili da ogni form della stessa procedura.

Anche su questo non sono poi così d'accordo, nel senso che lì tengo solo le tabelle davvero globali (clienti, documenti, utenti etc) e, soprattutto, le connection.

Quelle più specifiche, riferite ad esempio ad una singola/due form, li metto lì e basta, anzi per la precisione uso due datamodule + le sorgenti "private" per le singole form.

Lo scopo è duplice: da un lato avere datamodule che si vedano su un monitor da 27", e soprattutto rendere più facile la "migrazione" di una form tra un progetto e un altro, una sorta di (passami il termine) "incapsulamento".

Poi non è detto che questo sia il Verbo, ognuno si regola come più gli è congeniale

[123delphi321]

Originariamente inviato da franzauker2.0
Quelle più specifiche, riferite ad esempio ad una singola/due form, li metto lì e basta, anzi per la precisione uso due datamodule + le sorgenti "private" per le singole form.

scusa, non afferro il tuo punto di vista...perfavore potresti spiegarmi perche usi 'due datamodule + le sorgenti "private"'?
grazie

[franzauker2.0]

Penso che tdatamodule sia un concetto ben definito, ovvero una unit nella quale convenzionalmente si posizionano i componenti per accesso ai dati che saranno condivisi globalmente da tutta l'applicazione.
Tipicamente sono tconnection (cambiano a seconda del database e della libreria che usi), tquery, ttable e tdatasource (ovviamente con relativi "cugini" per le varie librerie).

Questo però non ti costringe, affatto, a mantenere solo e solo lì i componenti quali ad esempio le tquery.

Se, ad esempio, esiste una tabella "archiviosms" che viene utilizzata solo in una form (ad esempio che invia gli sms), allora piazzare una qryArchivioSMS nel tdatamodule, e magari pure una dsrArchivioSMS (un tdatasource con dataset che punt a qryArchivioSMS) (cosa che va benissimo) ha pregi e difetti.
Il pregio è quello di avere sott'occhio tutte le sorgenti-dati (questo è buono ad esempio per centralizzare gli eventi AfterEdit, AfterPost etc come fossero "trigger).
Il difetto (a seconda della dimensione del progetto e del riutilizzo del codice, se lo fai) è che da un lato nel tdatamodule puoi trovarti con 800 componenti, il che non è il massimo della vita quando lo apri a video e devi cercare la qryArchivioSMS tra altre 400 query diverse) MA, soprattutto, se vuoi trasmigrare la form "inviosms" tra due progetti.
Se i suoi componenti di accesso ai dati sono nel tdatamodule del progetto #1, dovrai fare il copia-incolla di questi nel tdatamodule del progetto #2 (cosa per nulla scontata, ci vuol poco a dimenticarsene uno, e questo diventerà "vuoto", ovvero potresti non accorgertene se non a runtime, due @@)

Se invece la form è indipendente (come fosse una classe vera e propria per capirci) ti bastera copiare i file nel progetto #2 ed aggiungere il relativo PAS.

Voilà il progetto #2 può inviare gli sms

ATTENZIONE al collegamento "fantasma" per la connessione la quale, ovviamente, deve esistere nel progetto #2 con lo stesso nome e nella stessa posizione (il tdatamodule).

Se rendi modulare il progetto ci può volere poco più di un minuto per dare capacità al progetto #2 per attività standard, tipo documenti, prima nota, documentale, email etc.

Spero di essere stato chiaro

[123delphi321]

grazie...sei stato molto chiaro!