Newsgroup: it.comp.appl.access
Titolo: Access & CDROM

Ho finito un lavoro dove c'e' una struttura dati molto complessa e ricerche
altrettanto complicate con molti parametri da maschere, stringhe SQL
costruite al volo ed un massiccio uso di tabelle di appoggio.
Il cliente, soddisfatto (!:-), mi chiede di distribuire il tutto ai suoi
utenti, utilizzando un CDROM. A questo punto, visto che sul CD non posso
scrivere, ho due strade, e chiederei un parere a chi le ha gia' praticate.
1) Creo una procedura di installazione che copia il FE da qualche parte.
Vantaggi: non devo rimettere mano pesantemente al programma.
Svantaggi: la procedura di installazione dovra' prevedere le situazioni piu'
disparate, ivi comprese la maggior parte delle lingue del pianeta. Inoltre
il clente vuole distribuire le "annate" dei suoi dati, e questo diventa
un'altro problema da gestire (tipo: infilo il CD 1999, lancio il FE, cambio
il CD...a qualcuno verra' in mente di farlo prima o poi!)
2) Creo un CD di sola lettura, quindi ho un FE per annata. (ah, il cliente
vuole pure che il CD a fine anno "scada" come il latte!)
Vantaggi: ci'ho tutto sul CD, se gira sul PC di tizio bene, senno' cavoli
suoi.
Svantaggi...devo riscrivere praticamente tutto trovando il modo di non usare
tabelle di appoggio. Ma...sono sicuro che sia possibile? Spesso si trata di
ragruppamenti e conteggi per tipo di dati selezionati precedentemente.
Quanti IN SELECT rischio di trovarmi a dover gestire? Inoltre: spesso ho
avuto bisogno di salvare la stringa SQL in una querydf per problemi di
lunghezza (runsql accetta max 2024 caratteri)...come potrei fare in quel
caso?
Grazie a chi e' stato paziente a leggere fin qui!:-)
Saluti.
Luciano
PS Ah, se c'e' qualcuno di Roma che vuole darmi una mano (pagata, of course)
e' ben accetto. Ci'ho anche tutto il discorso sulla sicurezza da
implementare.



Per quanto riguarda la soluzione 2 puoi creare un mdb di appoggio
nella directory tmp da utilizzare per le tabelle temporanee.
Ciao
---------------
Guido
guc...@gedy.it

nella directory tmp da utilizzare per le tabelle temporanee.
Ci avevo in effetti pensato, ma mi sono risposto che al db di appoggio
dovrei collegare le tabelle del db sul CD e percio'modificare la proprieta'
connect scrivendo dove non posso.
Ma....forse mi manca qualcosa!:-)
Domanda: come faccio a fare dei bei INSERT & SELECT sulle tabelle di un DB
esterno ?
Ho provato a creare un tabledef senza fare append e modificare connect sulla
tabelle esterna, ma non mi funziona.
Come si fa?
Grazie.
Luciano

esterno ?
SELECT * from NomeTabella IN 'C:\TMP\IlTuoDatabaseEsterno.MDB';
INSERT INTO NomeTabella IN IN 'C:\TMP\IlTuoDatabaseEsterno.MDB' blah
blah blah;
-- 
Ciao,
Giovanni

connect scrivendo dove non posso.
Ma scusa eh?
Tu prepari sul CD un FE e un BE. Al setup di installazione copi il FE
sull'Hard Disk, e togli l'attributo sola lettura al file.
A quel punto aggiorni le tabelle allegate sul FE (che è sull'hard disk e
quindi scrivibile) e stai a posto!!!
Questo ti consente anche di gestire (come tutte le soluzioni FE BE) gli
aggiornamenti dei dati e/o della struttura del DB.
Antonio

aggiornamenti dei dati e/o della struttura del DB.
Si, ma....
1) La lettera dell'unita' cdrom non sara' sempre la stessa...chi ci'ha la D,
chi la E e via dicendo. Quindi dovrei gestire che quando lancio la prima
volta il FE su HD devo andarmi a cercare qual'e questa lettera per aggionare
il connect delle tabelle.
2) Se uno cambia la lettera dopo l'installazione (tipo aggiunge un nuovo HD,
uno ZIP) si sfascia tutto....da gestire come situazione.
3) I dati saranno un CD per annata...da gestire anche un eventuale cambio a
programma avviato.
4) Comunque scrivere un setup e' una rogna....chi ci'ha 95, chi NT, chi non
ci'ha spazio su C ma su D...insomma, lo eviterei volentieri!
Comunque sono orientato a questa soluzione:
- Sul CD metto BE/FE fusi insieme, un DB con le tabelle di appoggio vuote.
- All' avvio del BE/FE mi copio il DBAPPOGGIO vuoto su C:\
- Le tabelle appoggio del BE/FE sono allegate a C:\DBAPPOGGIO . Siccome il
controllo sul connect non viene fato all'apertura ma al momento dell'uso,
non ci sono problemi.
- Fondo BE ed FE perche' non ho la possibilita' di sapere qual'e' il
percorso del BE (D, E,...) ne' di aggiornare i collegamenti. In questo modo
sono sicuro di trovare i miei dati. Del resto...a cosa servirebbe tenerli
divisi in questo caso?
- L'unica cosa che devo ancora risolvere sono le querydef temporanee...ma
non credo ci siano problemi a scrivere pure quelle su DBAPPOGGIO.
- Se l'utente vuole cambiare annata deve chiudere il programma ed e' quello
che vuole il cliente.
- All'uscita cancello DBAPPOGGIO dall'HD dell'utente e nessuno ne sapra' ma
nulla!:-)
Saluti.
Luciano
PS Ma nessuno ha gia' effettivamete fatto qualcosa del genere? Se si, in che
modo?

Scusate si m'intrometto ma una parte del problema si può risolvere
ispirandosi al messaggio di risposta che avevo scritto il martedì 7 marzo
2000 2.29 con come oggetto: "R: Problema con la divisione dei files
databases."
il succo è che a ogni avviamento una routine controlla la posizione delle
tabelle. Io la uso e funziona a meraviglia. Di colpo tutti i problemi di
posizione delle tabelle e di trasferimento di database scompaiono!
Con una routine più evoluta di quella che avevo suggerito, puoi benissimo
sapere a ogni avviamento di FE se c'è stato un cambiamento di qualunque
genere. Magari ti pari il cu... con una gestione degli errori nel caso di
unità non più esistenti (es.: non c'è il CD, il tizio ha messo il CD su una
seconda unità, ecc...) o nel caso di cambiamenti di posizione del database
sulla stessa unità, ecc....
E' strano come qui sapiate così bene programmare VB su Access e nessuno
utilizza questa soluzione!
Non dico che sia semplicissima, ma una volta fatta, la si può mettere in
tutti i databases che fate senza rimanegiare troppo il codice.

modo?
Io l'ho fatto, come ti ho spiegato!
Antonio