Newsgroup: it.comp.lang.delphi
Titolo: Accoppiata Delphi e Access ?

 E di questa accoppiata sono curioso. 
Cosa ne pensate?
Grazie.
Diego22
--- posted by geoForum on 
http://www.delphiedintorni.it

 Cosa ne pensate?
Io sinceramente non capisco la natura (o meglio, lo scopo ultimo) di 
queste domande. Sono l'unico? :-)
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

 Grazie.
Ci sono rimasto scottato. Tieni conto del fatto che la struttura di 
Access pare cambiare di versione in versione.

 
Penso che sia, semplicemente, dovuta al fatto che c'e' gente che deve 
ancora "innamorarsi" di un engine specifico. :)

 queste domande. Sono l'unico? :-)
Siamo in due.

 ancora "innamorarsi" di un engine specifico. :)
L'amore è cieco e in informatica è un lusso che non puoi 
permetterti...

no, non sei l'unico
AS

 Access pare cambiare di versione in versione.
all'inizio sembra tutto facile perchè il motore di accesso ai dati è 
incluso di default nel sistema operativo (WinXp, Win2000). 
Creare strutture dati e query è facile perchè c'è già un tool visuale di 
amministrazione (Microsoft Access).
Perchè Access non è il motore di accesso ai dati, giusto? Access è un IDE 
per creare maschere, report, "applicazioni" e per amministrare il database, 
o mi sbaglio? Il "motore" è il Microsoft Jet, al quale si può accedere 
tramire DAO e ADO, due "strati" che permettono di manipolare e accedere ai 
dati mediante dei server COM. 
Magari sto dicendo corbellerie ma questo è quello che mi pare di aver 
capito.
Tra l'altro non sono mai riuscito a creare trigger e stored procedures in 
Microsoft Jet (nè ho indagato a fondo se ciò sia possibile).
Non sono mai riuscito (con success) a manipolare da codice i permessi degli 
utenti sugli oggetti del database.
Addirittura in questo lungo 3ad ("access si può ritenere programmazione ad 
oggetti?")
http://groups.google.it/group/it.comp.appl.access/browse_frm/thread/5df6cea
713c339fd/f1fd5833798c7ff1?tvc=1&q=access+firebird+falzari&hl=it#f1fd583379
8c7ff1
si sosteneva che con Access si potevano creare applicazioni basate su 
qualunque motore dati, compreso Firebird!
 
http://tinyurl.com/86uhs
ma non l'ho sperimentato.
Secondo me, un grande problema (a parte il fatto che non si possono 
resettare i contatori dei campi autoincrementanti) di Access/Microsoft Jet 
è che è un sistema file-based. Non come Interbase o Firebird, che gli 
utenti (ovvero le applicazioni che girano sui pc degli utenti) NON hanno 
accesso diretto al file di database, ma passano attraverso solo 
attraverso un meccanismo client/server.
       (macchina/e client)
+-----------------------------------------+
| APPLICAZIONE CLIENT <-> FIREBIRD CLIENT |
+-----------------------------------------+
                                 |
                                 |
        +--------TCP/IP----------+
        |
        |
+------------------------------+
| FIREBIRD SERVER <-> DATABASE |
+------------------------------+
      (macchina server)
Non so, magari ho detto qualche corbelleria, casomai correggetemi.
-- 
Mauro Falzari 
 
 "Se guardi nell'abisso, anche l'abisso guarda in te." 
   (Friedrich Nietzsche)

 Non so, magari ho detto qualche corbelleria, casomai correggetemi.
Hai scritto tutte cose giuste, giustissime: e te lo dice uno che ci lavora
su da 4 anni (delphi+access).
In sostituzione di access, ora sto valutando sqlserver 2005 da accoppiare a
un framework .net, non ho ancora deciso se borland rad o microzozz rad.
Ciao!
-- 
Morde. 
ICLDweb: 
http://www2.samatel.com/icld/

 resettare i contatori dei campi autoincrementanti) 
A che servirebbe ?  Se ti serve fare una cosa del genere droppi e 
ricrei la tabella.

 un framework .net, non ho ancora deciso se borland rad o microzozz rad.
Devi prendere una decisione tenendo conto anche di un'altra 
considerazione: "voglio ancora avere la stima di Marco oppure no?" :-D
Scherzi a parte, tieni conto del fatto che D2006 integra i driver 
aggiornati per Microsoft SQL Server 2005 per dbExpress (VCL, Win32/.NET) 
e BDP (solo .NET, con WinForms e 
ASP.NET
). ;-)
Ciao,
   Marco.


 resettare i contatori dei campi autoincrementanti) 
Protesto vivamente contro questa esigenza! :-)
Ogni volta che mi capita di fare un corso o di fornire supporto tecnico 
in qualche modo, mi viene sempre chiesto come è possibile far ripartire 
la numerazione, oppure ancora quali metodi si possono utilizzare per 
"riempire i buchi" dovuti a record cancellati.
La mia risposta è sempre la stessa: occorre infischiarsene della 
numerazione, serve solamente a generare con sicurezza un numero univoco 
da inserire all'interno di un campo che non deve avere altro significato 
intriseco se non quello di stabilire un legame tra due tabelle correlate 
tra loro usando un tipo di dato confrontabile facilmente e velocemente, 
nulla di più. :-)


 numerazione[...]
Concordo pienamente.
I programmatori sono ossessionati da incubi assurdi, come quello 
che i numeri naturali possano terminare.  Se avessero il buon 
senso di calcolare per quanti anni girerà, al massimo, il loro 
software, non si porrebbero proprio il problema di riempire buchi 
o riinizializzare la numerazione.  Ci sono DB, vedi Firebird, in 
cui è possibile creare campi generatori a 64 bit.  Non so quanti 
potranno mai avere nel proprio DB 18446744073709551616 record.

 "riempire i buchi" dovuti a record cancellati.
Ci puo' essere qualcuno (no, non sono io) che sfrutta questa 
caratteristica di Access per avere un codice univoco autoincrementante 
senza buchi come, ad esempio, i numeri progressivi delle fatture.
Li' non *devi* avere buchi.

 Li' non *devi* avere buchi.
Capisco pienamente, non volevo affermare la mancanza assoluta 
dell'esigenza, in qualsiasi condizione, di avere un campo contenente un 
numero progressivo; semplicemente, non legherei questa condizione 
proprio all'ID del campo di tipo autoincrementale. :-)
Nell'esempio che hai fatto, ad esempio la numerazione di documenti 
fiscali, basterebbe avere una tabella contenente il numero progressivo 
da utilizzare per il prossimo documento, magari sfruttando "constraint" 
e procedure di controllo per impedire l'attribuzione di numeri identici, 
utilizzando correttamente le transazioni in ambiente multiutente.
Non legherei insomma questa funzionalità ad un campo che si 
autoincrementa per un motivo differenze, spesso senza possibilità di 
controllo diretto.
Ciao,
   Marco.


 senza buchi come, ad esempio, i numeri progressivi delle fatture.
Pessima tecnica.  I campi autoincrementanti non andrebbero MAI 
usati per sequenze in cui non debbano esserci buchi.  Questa è una 
regola che si dovrebbe conoscere.

 controllo diretto.
Pero' ho visto cose che voi essere umani non potreste nemmeno 
immaginare... tra cui anche quella che ho detto nel mio messaggio.


Hai usato l'ottima forma verbale condizionale... :)

 nulla di più. :-)
rispondo ad Andrea e a Marco.
E' un caso limite e neanche tanto comprovante dell'assoluta necessità di 
inizializzare i contatori a un valore X, ma rende l'idea.
Una ditta ha sedi in due località differenti, distanti pochi chilometri una 
dall'altra. Non intendono spendere dei soldi per collegarsi con ADSL, ma 
mantenere le loro vecchie connessioni a 56K.
Mettiamo di avere un programma di gestione ordini e clienti, mettiamo che 
sia appoggiato su file MDB. Abbiamo bisogno di chiavi primarie univoche 
sulle tabelle ORDINI e CLIENTI.
Su tutti i pc di ciascuna delle due sedi gira il nostro programma, che si 
collega al file MDB posto in una "cartella condivisa" (share di rete) 
presente su un computer che in ciascuna sede "fa da server".
Quindi abbiamo due database MDB.
Abbiamo una procedura di riconciliazione dei dati tra le due sedi, che 
viene attivata manualmente una volta al giorno e viaggia sulla connessione 
56K, o su un floppy portato a mano da un impegato tra una sede e l'altra.
Per mantenere l'unicità delle chiavi, devo avere nella sede #1 un MDB con 
tutte le tabelle le cui primary key vanno da 1 a un miliardo (poniamo) e 
nella sede #2 devo avere le primary key che vanno da un miliardo+1 a 2 
miliardi.
Prima di far partire il sistema, allora dovrò prevedere una procedura che 
inserisca ed elimini un miliardo di record nel database MDB della sede #2, 
per la tabella CLIENTI e la tabella ORDINI. Questo è l'unico modo che ho 
per fare questo in Access.
E poniamo che le tabelle non siano solo CLIENTI e ORDINI, ma diverse 
decine...
Certo, la cosa è fattibile ma è parecchio lunga e noiosa, se penso che in 
Firebird si risolverebbe con una sola riga di script (una per 
generatore)...


 per fare questo in Access.
Non è così che si gestisce una cosa del genere.
Per problemi di questo tipo, per i quali cioè sia previsto che i 
dati vengano gestiti in due sedi separate e poi riconciliati in un 
terzo punto, è necessario aggiungere, alla chiave primaria dei 
record, il codice della sede.  Se la sede è ROMA1 con codice RM1 e 
  MILANO3 con codice MI3, allora i record avranno in chiave il 
codice della sede e l'autoincrementante.

 Hai usato l'ottima forma verbale condizionale... :)
Allora te la metto in questi termini: NON SI DEVONO usare i campi 
autoincrementanti per gestire sequenze in cui non debbano esservi 
buchi.


Scusa, mi sono espresso male.
Volevo dire: hai fatto bene ad usare il condizionale perche' c'e' gente 
che lo fa lo stesso anche se si dovrebbe non fare.
Piu' chiaro, ora?

 immaginare... tra cui anche quella che ho detto nel mio messaggio.
Nel senso che hai visto qualcuno trattare i campi autoincrementali 
esattamente nel modo che ho denunciato (negativamente)? :-)
Se per quello, li ho visti anche io, proprio per questo protesto 
contro... :-P
Oppure non ho capito ciň che hai voluto intendere. :-|


 esattamente nel modo che ho denunciato (negativamente)? :-)
Purtroppo hai colto nel segno.

 inizializzare i contatori a un valore X, ma rende l'idea. [...]
Nel caso che hai presentato, così su due piedi, io agirei utilizzando 
l'ID autoincrementale Access (anche se non userei Access) esclusivamente 
per le relazioni delle tabelle che appartengono al database stesso, ma 
aggiungerei un campo secondario, gestito manualmente secondo una 
convenzione di codifica che consenta di legare ciascun record al record, 
o ai record, correlati nelle tabelle che appartengono ad un altro DB.
Insomma, per dirla in breve, cercherei la soluzione alternativa che mi 
consente di raggiungere lo scopo senza appoggiarmi ad un campo 
incrementale. :-D
Ciao,
   Marco.


 Purtroppo hai colto nel segno.
"Lo ben so" (cit. Aldo, Giovanni e Giacomo), infatti ho già portato ad 
esempio le domande che mi vengono rivolte a riguardo, che spesso se non 
sempre si traducono in intenti veri e propri nonostante i miei anatemi. :-D


 lavora su da 4 anni (delphi+access).
ah, dimenticavo:
se si lavora in multiutenza e il database MDB č in una cartella condivisa 
(share di rete), bisogna assicurarsi che la cartella in questione sia 
inacessibile agli utenti, sennņ puņ sempre capitare il furbo di turno che 
preme un bel CANC per sbaglio sul file MDB contenente decine di migliaia di 
record e dati relativi ad anni interi... (i file cancellati dalle share di 
rete non vanno nel Cestino).
Ma se c'č l'accesso a chiunque al file MDB, un utente distratto potrebbe 
anche aprire Access e premere CANC su questa o quell'altra tabella, al che 
Access gli chiederebbe
"Eliminare la tabella CLIENTI ?"
"Per ulteriori informazioni su come evitare la visualizzazione di questo 
messaggio ogni volta che si elimina un oggetto, consultare la Guida in 
Linea"
Bello, no?


 buchi.
giusto, se la chiave autoincrementante č poniamo a 1000, poi aggiungo un 
record e lo elimino, quindi aggiungo un altro record, questo avrą la chiave 
a 1002, mentre del 1001 non c'č traccia.


 incrementale. :-D
avete ragione. Però in Access/Jet, non essendovi i triggers, la logica 
dev'essere gestita per forza al di fuori del database.


 Bello, no?
Ho dovuto convertire un'applicazione di gestione inventario che usava 
VB/Access in Delphi/IB.
Ho scoperto che il software precedente non prevedeva stampe che venivano 
tutte fatte dalla signora che usava il programma tramite Access.
Detta signora aveva anche "l'assoluto potere" su tutte le tabelle.
Bello, no?

 considerazione: "voglio ancora avere la stima di Marco oppure no?" :-D
Ahahaha sei un mito, non ci son cazzi: il mito di it.comp.lang.delphi sei
tu! :-D
Ci pensero' su molto, anche perche' soldi non ce ne sono tanti in azienda e
infatto sono rimasto a D6 da 4 anni!
ciao "Marchino" (come ti chiamo in chat) sei un grande!
^____^


 Per mantenere l'unicità delle chiavi,
Scusa forse mi sfugge qualcosa: per chiave cosa intendi, numero doc o
qualcosa d'altro? Il mio punto di vista e' che potresti avere chiavi
alfanumeriche, un guid ad esempio, dove anteponendo la lettera "A" per la
sede A e la lettera "B" per la sede B hai gia' la separazione dei due
domini.
Per quanto riguarda i contantori, io ho realizzato cose simili in passato e
me la sono sempre cavata riferendomi ad una tabella CONTATORI per l'appunto
che puo' essere gestita e "aggiustata" nella numerazione da un utente
appositamente dotato di password.


   (Friedrich Nietzsche)
Se un'azienda ha 2 miliardi di ordini e clienti si potra' di sicuro 
permettere un'adsl :P
magari una bella fibra ottica cosi' noi programmatori possiamo arronzare 
ancora di + heehheheehe

 tabelle. Bello, no?
sě, cioč no.
La controparte č che in Delphi devi scrivere tu tutti i report (cosa 
noiosissima).



nella tabella CONTATORI ci scrivi da un'applicazione esterna e non proprio 
da dentro il database. Comunque all'atto pratico penso siano delle 
sottigliezze.


 noiosissima).
La controparte della controparte e' che la signora ha causato, piu' di 
una volta, inenarrabili macelli all'interno della struttura dati.
Quando ho installato il mio programma si aspettava una cosa simile ad 
Access. Il programmatore che aveva fatto il vecchio programma mi aveva 
detto che la signora pensava che lui avesse scritto Access. :(

 permettere un'adsl :P
Onestamente, lo pensavo anche io finche' non ho conosciuto certi nostri
clienti che, pur essendo miliardari, ti portano il portatile di 10 anni fa
chiedendo se si puo' installarci un win98 giusto per "non sprecarlo".
Ecco vedi... ti dico sinceramente una cosa: ieri il mio amico (e lo dico
con orgolio) guastatore mi ha scritto una frase su persone come queste:
"quando vanno a fare il tagliando del jeeppone e gli chiedono 300 euri, non
battono ciglio: tu per mettergli a posto windows virato glie ne chiedi la
meta' e ti dicono che sei un ladro, che gli togli la pelle di dosso.."
Purtroppo chi piu' ne ha, piu' se li tiene stretti!
Ciao!


 Morde.
Tristemente vero....
-Spettro