Newsgroup: it.comp.appl.access
Titolo: Come mettere i report 'dentro' il db ?

Stavo pensando al fatto che, una volta avviato e stabilizzato un 
gestionale, le modifiche piu' frequenti sono sicuramente le stampe
Ora, aggiungere una semplicissima stampa o modificarla, su un gestionale 
esistente realizzato con Access e distribuito su mde/accde, vuol dire 
fornire l'intero mde/accde (se programma e report sono dentro unico file)
Se le stampe fossero memorizzate nel db, basterebbe da una postazione 
aggiungerne una o modificarne una esistente, ed automaticamente tutte le 
postazioni lavoro avrebbero a disposizione i nuovi report
Ora, essendo i report sostanzialmente trasformabili in file di testo 
(con la funzione Application.SaveAsText) mi chiedevo se fosse possibile 
'infilarli' in un campo di una tabella del db e poi 'tirarli fuori' al 
volo ed usarli per stampare
Che dite?
 

Un modo abbastanza comodo è realizzare un ACCDB/MDB con solo i report ed inserirlo nei riferimenti dell'applicativo usandolo come fosse una libreria esterna in earlybinding o se vuoi latebinding per essere meno vincolato...
Link delle tabelle indispensabili ai report e fine.
In quel caso distribuisci solo id DB dei report.
 
@Alex


Si, grazie
Conosco questo sistema e ho provato ad usarlo qualche tempo fa
Onestamente non mi e' piaciuto granche' per il fatto che comunqne se hai 
10 postazioni lavoro devi aggiornare il file stampe su ogni postazione e 
soprattutto ricollegare le stampe ai dati
Non l'ho trovato sostanzialmente diverso dall'aggiornare l'intero mde 
contenente programma+report
Piu' che una reale necessita' era la volonta' di capire se sia 
percorribile la strada della memorizzazione report dentro il db ed 
effettivamente quali siano le difficolta'  e pregi/difetti di questa 
soluzione


Non hai mai pensato di copiarti localmente il file coi report all'apertura degli accde in ciascuna postazione sovrascrivendo il vecchio?
 
Ciao


La copia sarebbe niente, ma oltre alla copia bisogna avviare anche il 
ricollegamento tabelle
Che in termini temporali, non e' poca cosa

 soluzione
 
provo a dire la mia, forse sto banalizzando perchè comunque NON ho esperienza su procedure complesse ...
 
SE il lancio del FE (mde/accde) avviene con uno script che ricopia (ad ogni avvio) il FE da una "cartella server" 
si tratta di paragonare il tempo necessario per l' aggiunta delle modifiche al file di sviluppo (mdb/accdb) con quello necessario per ottenere quello che stai
ipotizzando
Nel mio caso (procedure piccole) mantengo la modalità  dell'aggiornamento dell'INTERO FE

 Che in termini temporali, non e' poca cosa
 
Roberto parliamo di un MDB/ACCDB preposto ai REPORT... quindi se relinkare le tabelle è un problema direi che hai un problema... con gli UTENTI che la prima cosa che fanno è APRIRE l'applicativo in 1 secondo e stampare...
 
Come ti suggerisce SIB, sovrascrivi il file con uno script VBS e sempre nello script allunghi 3 righe di codice per ripristinare la Connection String delle tabelle... sempre che serva... perchè le Tabelle se rimangono nel SERVER usando Riferimenti Relativi "\\NomeServer\Nomedb" se si tratta di Access o la stringa di connessione a SQL o quello che è non serve nulla.
 
Lo script di cui sopra ha il vantaggio di avere un processo ASINCRONO quindi assolutamente non visibile dall'utente che non ci credo nemmeno se lo vedo che in 1 secondo si mette a stampare...
 
Dai non complicarti la vita con cose facili.
 
@Alex


Se su postazioni lavoro caricassi ogni volta da server il front-end, 
dovrei attendere circa 0.2 sec/tabella x 370 tabelle = 74 secondi per il 
ricollegamento tabelle
Ad ogni avvio, e' un'attesa inaccettabile


Infatti non si deve fare... basta 1 volta durante il REPLACE non del FE, ma del DB(Report) sovrascritto e ricollegato in background dopo la sovracrittura...
1 volta...
 
@Alex


Chi e' SIB, GiorgioDaPrato o Davide La Mantia?
Dici che potrebbe non servire ripristinare il percorso tabelle/db?
Allora, supponiamo che io sviluppo da postazione1, db in postazione2 
percorso postazione2\c:\db\peppe.db
Quando ho finito devo passare il file mde sulle postazioni lavoro, 
quindi postazione3, 4 e 5, che si collegano al db in postazione6
Normalmente metto il file in postazione6, i vari client (3,4,5) al primo 
avvio si 'accorgono'  del nuovo programma aggiornat, lo tirano giu' 
dalla postazione6 e lo mettono in  locale, poi lo avviano
Il file mde/accde che hanno appena scaricato dal server ha memoria del 
percorso tabelle di quando e' stato prodotto (postazione1, e db in 
postazione2)
Credo sia indispensabile un relink tabelle al primo avviamento da 
postazione3,4,5 , oppure no?
Quel "..tre righe di codice.." di cui parli non e' il problema
Il problema e' il tempo necessario ad eseguirle
Certo che se trovassi modo di evitare il relink tabelle, tanto meglio


Ciao,
SIB sono io, era il mio Nick 18 e passa anni fa...
Ok, diciamo che ricopiare e ricollegare le tabelle può essere un problema.
Puoi provare una importazione dei report dal db remoto sul db locale:
elimini il report locale e lo reimporti
Puoi fare una tabella delle versioni dei report e quando il fe trova in tabella una nuova versione elimina il report locale e importa il report remoto nel db locale.
 
Ciao


D'altro canto, se il db remoto ha le tabelle collegate tramite percorso di rete, ricopiandolo non devi ricollegare le tabelle.
 
Ciao

Esatto...
 
@Alex 


Ah non sapevo, piacere RobertoA
In che senso 'db locale' ?
Intendi forse il file mde/accde delle postazioni lavoro?
Si e' proprio questo che vorrei fare, trattare coi singoli report 
piuttosto che gestirli tutti su unico file, solo che non ho ancora ben 
chiaro come passarli da server alle singole postazioni lavoro
Ciao
 

 
 
Come da esempio precedente, se sviluppo su postazione1, db in 
postazione2 percorso c:\db\peppe.db (di una rete), compilo e mando tutto 
su postazione6 (di altra rete) db in d:\database\ciucciamariuccia.db 
allora le postazioni3,4,5 quando tirano giu' il nuovo file (programma 
e/o stampe) e tentano di collegarsi al db in postazione6 DEVONO relinkare
O sballio?
 
 

 Ciao
 
questo è quello che vale anche per me
ovviamente vale per tabelle collegate direttamente su BE Access.
 
NON SO quello che accade (e vale) per tabelle collegate via ODBC
ad un altro tipo di BE (server sql ?):
NON NE HO ESPERIENZA DIRETTA 
 
e ancora:
puoi mappare la "cartella server" di rete aziendale (\\ecc...) con un drive "di comodo" (W:\) e fare le modifiche sul tuo PC
e anche questo passaggio è da inserire nello script di lancio del FE (mde/accde)

 O sballio?
 
aggiunta (NON avevo visto questa continuazione):
 
 
penso che possa aiutare (risolvere ?) mappare le risorse di rete con un drive virtuale e inserire il suo riconoscimento nello script di lancio del FE 


Roberto conosci la differenza di un PERCORSO visibile in RETE da uno NON VISIBILE...? Sicuraente si...!
 
Quindi se il TUO SERVER è il PC1, è evidente che NON puoi linkare le Tabelle con C:\Pippo\Poluto\TuoBE.mdb
 
\\NomePcInRete\..... ecc...
 
Il Percorso deve essere accessibile dalla Rete, quindi, privilegi di condivisione innanzitutto(SHARED FOLDER), ma devi introdurre un PERCORSO di Macchina...
 
@Alex


Certo che lo conosco, e allora?
 
Ripeto per la terza volta, io sviluppo su postazione1, dati su 
postazione2 in c:\db\peppe.db
 
Chi usera' il programma, (postazioni3,4,5) vede i dati sulla postazione6 
in d:\database\ciucciamariuccia.db
 
Aggiungiamo pure, per capire meglio, che lo stesso programma sara'usato 
anche da postazione7,8,9 che vedranno i dati sulla postazione10 in 
e:\vattelapesca\ciucciamariuccia.db
 
Dici che quando, dalla mia postazione1, mando il nuovo programma (o 
stampe) alle due sedi operative diverse (che hanno il db su PERCORSI 
diversi), non devono relinkare?
 
 

 diversi), non devono relinkare?
 
sono sempre convinto che agire CON UNO SCRIPT DI LANCIO FE in modo da mappare con lo stesso drive virtuale le varie cartella che contengono il BE (riconoscendole nello script con l'istruzione che verifica la presenza di una cartella o file e poi imponendo la mappatura) faccia al caso tuo (come lo ha fatto al mio ...)


aggiunta:
pensi ti possa agevolare l'ipotesi di consegnare un BE in cui TUTTE le tabelle Access (le tabelle NATIVE Access DIRETTAMENTE collegate al FE)
si "vedono" dal FE in questo modo --> (W:\miaTabella1 ... W:\miaTabella371)
 
SE SI', questo è fattibile, ovviamente almeno con un relink (però penso proprio che sia da fare SOLO nella macchina di sviluppo)


In che senso 'consegnare un be' ?
Il database e' quello e resta quello dal cliente, una volta installato 
la prima volta non si tocca piu' a meno di aggiornamenti versione db server
Ma forse non ci capiamo
I dati sono su un quasiasi db server, postazione \\server1
Le postazioni lavoro1, 2, 3, usando il loro mde/accde, accedono ai dati 
via driver odbc
Il problema sta nel fatto che quando io sviluppo 'vedo' i dati su 
\\pippo\c\db_sviluppo\dati.db  mentre le postazioni lavoro del cliente 
sede1 vedono i dati su \\server_sede1\d\db_azienda\gestionale.db, nella 
sede2 i dati sono su \\server_sede2\e\db_azienda\gestionale.db
Quindi quando mando un nuovo mde al cliente, il file mde stesso ha 'in 
corpo' il percorso \\pippo\c\db_sviluppo\dati.db
Ovviamente al primo avvio del nuovo mde inviato a sede1 e sede2 bisogna 
relinkare altrimenti il codice non trova i dati
 

 relinkare altrimenti il codice non trova i dati
 
(risposta al volo invio poi qualche dettaglio sui comandi di mappatura,
e un esempio di un mio script)
NON E' COSI' SE la cartella del PC dove hai il BE nel PC di sviluppo
la rimappi come disco virtuale (W:\  X:\ Y:\ Z:\ ....)
e con il FE di sviluppo colleghi le tabelle del FE 
che in questo modo rimangono con il percorso 
(W:\  X:\ Y:\ Z:\ ....)\miaTabella.
 
Nei PC di utilizzo procedura (ditta)
ugualmente mappi le cartelle dove poni il FE con la stessa lettera
 
istruzione che fa la MAPpatura di una qualsiasi cartella (locale o di rete):
vecchio comando DOS (NON è permanente)
nuovo comando similVBscript (ha l'opzione di renderla permanente)
 
QUESTA ISTRUZIONE va messa in uno script che lancia il FE 
 
 
 

 ugualmente mappi le cartelle dove poni il FE con la stessa lettera
 
SI
 e con il FE di sviluppo colleghi le tabelle del BE 
 che in questo modo rimangono con il percorso 
 (W:\  X:\ Y:\ Z:\ ....)\miaTabella.
 
 Nei PC di utilizzo procedura (ditta)
 ugualmente mappi le cartelle dove poni il BE con la stessa lettera


Vedo che non e' molto di moda leggere i post
Elora ricapitolo, supponiamo di usare Sql Server come back-end
 
Io sviluppo su pc1, vedo i dati su \\pc2\sql2014server  db PIPPO
 
Quando finisco una nuova release, compilo e mando alla sede1 e sede2
In sede1 le postazioni1,2,3 vedono i dati su \\server1\sql2008server  db 
PEPPE
 
Stesso mde lo mando in sede2, le postazioni4,5,6 vedono i dati su 
\\server2\sql2012express db POPPO
 
Dici che posso evitare di farli relinkare?
Io non credo, la prima volta che avviano DEVONO relinkare
Stessa logica seguirebbero anche le stampe, in gruppo o singole che fossero
 
 

 
 
 è vero, ho allungato inutilmente:
 
ho premesso che NON HO NESSUNA ESPERIENZA su tabelle NON NATIVE di Access
e quindi credo collegate via ODBC
 
Quello che ho descritto vale per tabelle NATIVE di Access,
io arrivo ad adoperare SOLO quelle, 
e con quelle il meccanismo descritto funziona
 


Robero è evidente che la 1° sia necessario il RELINK, ma mi chiedo come puoi pensare che durante l'UPGRADE non sia tollerabile un tempo di latenza per la preparazione.
 
L'upgrade come lo fai con un COPIA/INCOLLA del File...?
Io una volta usavo ad esempio INNOSETUP, e con uno SCRIPT su POSTINSTAL andavo a ripristinare le LINKED TABLE, cosa esattamente identica a farlo con uno script VBS peraltro...
 
Non riesco a capire questa cosa... mi sono astenuto perchè sicuramente do per scontate cose che mi pare non aver inquadrato completamente, e le poche risposte che ti ho dato mi hanno lasciato in difficoltà non tecnica ma di comprensione...
 
Boh....
@Alex


Ti consiglio, caldamente, di adoperare un db server qualsiasi per tenere 
i dati cui Access accede
L'utilizzo in multiutenza dei dati su file mdb, a mia esperienza, non e' 
mai stato granche' affidabile
La difficolta' e' uguale, tanto vale affidarsi ad un vero db server che 
di mestiere faccia quello
Gia' il Sql Server di casa Microsoft, versione express e quindi 
completamente gratuito, va benissimo