Newsgroup: it.comp.appl.access
Titolo: Automazione Word o Stampa Unione...?

La questione per me č piuttosto complessa da spiegare....!
Devo gestire Schede di Taratura Strumentazione.
Ho diversi Modelli di Schede in formato SchedaXX.Dot
che utilizzo per realizzare le varie schede, una scheda per
ogni strumento.
Spiego perchč una scheda per strumento per non incorrere
nella logica obiezione..........!
La scheda di taratura su Word come NomeStrumento.Doc
contiene dati che non devono e non possono essere salvati nel DB
quindi vengono inseriti all'occorrenza direttamente nel XX.Doc
Il tutto funziona egregiamente bene in fase di Generazione della
Nuova scheda di taratura, ho inserito dei Campi nei Modelli.Dot
che sfruttando l'Automazione di Word vado a compilare in seguito
alla compilazione dell'utente della Tabella in Access.
Tutto regolare.
Il problema mi capita quando devo modificare i dati relativi ad uno
strumento....................!!!
Non avendo piů i Tag nel Nomestrumento.Doc non mi č rimasto
che cercare il Vecchio contenuto con FindText e sostituirlo con
il nuovo utilizzando ReplaceWith..............!!!
Ora funziona tutto, ma mi pare una enorme perdita di tempo.......!!!
Chiedevo se qualcuno che ha piů esperienza di gestione tra le Automazioni
dei prodotti Win abbia mai affrontato un problema simile e abbia soluzioni
alternative.
Credo di essere stato poco chiaro, ma come dicevo la cosa piů complessa
č quella di fare capire ad altri ciň che non si capisce............!!!!
--
@Alex

 ha scritto nel messaggio
news:od4Fa.74342$lK4.2...@twister1.libero.it...

Le strade che sto percorrendo sono:
- segnalibri;
- variabili documento;
solo che se inserite nel documento master, poi nel documento creato dalla
stampa unione non ne ritrovi nessuna delle due.
A tutt'oggi la tua soluzione (cerca e sostituisci) č l'unica via; sono in
attesa che il sangue mi affluisca nella cervice e mi faccia accendere la
lampadina...
Ciao.
--
Sergio MAZZA

 Sergio MAZZA
Ero certo del tuo intervento...., ci speravo almeno...!
In effetti la cosa funziona, ma, scusa il gioco di parole, è
veramente poco funzionale.
Dalle prove fatte con il Merge dei Campi, la cosa risulta
molto più flessibile e Error-Free, visto che devo scrivere
2 volte(1° Tabella, 2° File).
Il grosso difetto è che quando apro il DOC in merge con
Access viene sempre aperta una nuova sessione di Access, nel
mio caso del BE.
Ciò mi scoccia molto, anche se è data dal funzionamento in uso.
L'altra cosa è che in ogni caso risulta poco agevole modificare
la Stringa OpenDataSource ed in particolare "SQLStatement" perchè
non ho ben capito, ma non funziona benissimo, anche se credo sia
colpa mia......!
Avreipensato di realizzare una Function nel Modulo di Word
che usando DAO va a pescare i dati dal Recordset della TABLE
da collegare in base ad un predicato SQL che passo alla Function.
Il bello poi sarà usare i Segnalibri per la compilazione
dei campi.......!
Mah.....................
Grazie.
@Alex.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 @Alex.
Calma; io pero' non ho capito se quando hai effettuato il mailmerge devi
rimodificare il documento creato o no... Almeno dal tuo primo messaggio
capivo questo.
Spiegami meglio tutti i passaggi che devi fare...
Ciao.
--
Sergio MAZZA

 Sergio MAZZA
Si lo devo poter modificare, ed è per questo che torna utile
il Merge, in quanto mi basterebbe modificare l'MDB ed aprire
il DOC filtrandolo per INDEX....!
Il problema sostanziale è che non ho 1 DOC per strumento, il chè
contrasta con l'utilizzo del Merge, ma come ti spiegavo ho dei
dati differenti per ogni DOC che non devo salvare nel DB....!
Ciao.



I dati differenti per ogni doc li conosci prima o dopo aver effettuato il
mailmerge?
Ciao.
--
Sergio MAZZA

 ha scritto nel messaggio
news:bc77pg$bv2$1...@canarie.caspur.it...

Li conosco dopo, ma non solo li posso modificare da Word.
In pratica sono i dati caratteristici per la taratura di Strumenti
di misura, che variano a seconda dello strumento e dell'utilizzo.
Per questo ho diversi DOT(uno per tipo di strumento) e devo
poter modificare i dati in base alle esigenze.
Non ho sviluppato il tutto in DB poichè le variabili alle quali
si va incontro sono troppe, e la gestione relazionale diverrebbe
molto pesante.
In oltre i documenti ufficiali anche ai fini fiscali sono quelli in DOT
e devo tenermeli......................!!!
Ho fatto altre prove con il Merge, ma proprio non riesco a dargli
in pasto la QRY SQL o almeno il Filtro in base alla mia chiave
recuperata da Access............!!!
Chi l'ha dura la vince.
@Alex.

 mio caso del BE.
Io uso pesantemento la stampa unione Word collegata ad un db di supporto
che contiene dati temporanei e ti posso dire che se il programma originale
è in formato compilato (.mde) il BE di supporto si apre e si chiude da
solo, quindi se il comp è veloce non ti accorgi nemmeno che qualcosa è
stato aperto. Prova!
Ciao
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Ciao
Ciao Diego, grazie per l'intervento.
Ho in parte risolto alcuni problemi di Automazione con Word, ma
il BE che risulta essere BE sia per Word che per il mio FE non può
essere MDE.
Ne cosegue che apro il FE e tutto bene, apro Word e apre una sessione del
BE,
ma ancora OK, il problema è che non la chiude.
Io devo lavorare in Multiutenza, e la cosa non mi piace, sicuramente dipende
da una mia dimenticanza o un errore, ma alla luce di come ho strutturato il
tutto
non sò che fare.
Già è molto che sono riuscito ad impostare da codice la connessione di Word
con il BE
e non posso fare diversamente visto che i miei DOC sono tutti diversi e
hanno una
SQLStatement differente in base alla Primary_Key........!
Forse ho mosso ancore di più le acque di quanto non abbia già fatto...??
Porta pazienza.
Ciao grezie.
@Alex

 Io devo lavorare in Multiutenza, e la cosa non mi piace, sicuramente 
Non hai capito, il Front-end deve essere compilato, non il BE! Basta che
il programma gestionale sia in formato mde e che usi BE mdb qualsiasi che
la stampa unione creata da codice (anch'io faccio in questo modo per DB in
multiutenza) apre e chiude la sorgente dati, fidati. 
La mia soluzione in breve è questa:
1)In base alle esigenze preparo i dati che servono alla stampa unione e li
copio in una tabella su un database mdb di supporto, così evito di
appesantire il BE generale. 
2)Prendo il modello di file Word che serve e lo copio sul computer
dell'utente
3)Apro questo file, gli attacco la sorgente dati, eseguo il merge e stacco
la sorgente dati, così alla fine ho documenti Word puri non collegati che
l'utente può salvare, stampare ecc.
Se gli utenti usando FE Access compilati la sorgente dati si chiude da
sola.


 @Alex.
Ciao.
--
Sergio MAZZA


Ci sono riuscito da codice, la TmpTBL non mi piaceva molto anche se sarebbe
stata l'unica soluzione sicuramente funzionante.....!
1° Ora mi rimane solo un Problema, se apro il DOC(Merge--BE) come si diceva
mi apre una sessione di BE, se chiudo DOC non si chiude la sessione di BE.
Se si genera un errore non si chiude BE, ma come faccio a controllare le
sessioni
aperte del BE.....???
2° Se lavoro in multiutenza, come devo fare quante sessioni di BE mi vengono
aperte..??
Non saccio.
Ciao buon Week_End.
@Alex.


Diego porta pazienza ma il caldo o la sklerosi mi danneggiano.....!
Provo subito la soluzione del FE--MDE che peraltro č quello che abitualmente
faccio.
Mi incuriosisce invece il 3° punto, e gradirei un'approfondimento, in
particolare
non capisco se rimuovi via codice gli attributi del metodo
OpenDataSource...????
Io in effetti via codice genero il Merge, ma non ho pensato a rimuoverlo...!
Mi sembra un'ottima idea, ma se mi illumini meglio ti sarei grato.........!
Buon Week_end a Lunedě..........!
@Alex.


Grazie, anche a te...
--
Sergio MAZZA

 
Si sò che usa DDE, ma sò che da me in Locale se uso FE=BE apre 2
sessioni, ed era per questo che mi preoccupavo, in ogni caso
ora faccio anch'io qualche tentativo.....!
Ciao.
@Alex 
