Newsgroup: it.comp.appl.access
Titolo: (semi OT e molto difficile) Eseguire applicazioni su macchine remote tramite COM

premessa : lavoro in una rete che supporta l' architettura 
com. Le macchine sono indirizzabili con la sintassi : \\macchina\directory\file 
 
mi riferisco all' excel ma come vedrete e' tutto trasportabile
in Access, mutatis mutandis : 
 
vorrei scrivere una applicazione vba excel  sulla mia macchina 
A che a un certo punto 
- "apre" una application.excel su una ALTRA macchina B 
  (ma in modo tale, attenzione, che sia la cpu della macchina 
  B e non la mia a lavorare) 
 
- apre un workbook (sempre DELLA MACCHINA B) 
- gli passa dati e parametri 
- fa partire una applicazione vba contenuta all' interno del 
  workbook 
 
A quel punto la mia applicazione (quella che gira su A) se 
ne frega : tutto il carico di lavoro sta sulla macchina B 
 
Quando la B termina dovrebbe in qualche modo comunicarlo 
alla mia applicazione. 
 
So per certo (letture, esperimenti) che il tutto e' possibile
sfruttando l' architettura COM 
 
Ad esempio se voi fate, dalla macchina A : 
dim Exl as excel.application 
set Exl = createobject(\\macchina, excel.application) 
 
osserverete nel "gestore attivita'" della B (nella colonna 
dei processi attivi)  miracolosamente  la  comparsa  di un 
processo excel : siete riusciti, con quelle semplici 
istruzioni, ad attivare una applicazione excel sulla 
macchina B. 
 
Purtroppo pero' non sono mai riuscito ad andare oltre 
questo passo elementare. 
 
Vi ringrazio
 
 


Forse ho trovato come si deve fare ma mi pare troppo facile.
Se fatalita'  dovesse  funzionare  (non si sa mai) vi faccio 
sapere. 
 

 sapere.
 
Eh, e facci sapere
 

 Eh, e facci sapere
 
Nisba, fallisce. 
 
Dim EXL as excel.application
dim WB  as excel.workbook
 
set EXL = createobject("excel.application", "\\nome_pc_remoto")
 
Fin qui e' una spada : sul pc remoto si apre il processo excel 
(lo vedo) ma nel momento in cui faccio : 
set wb = exl.workbooks.open ("\\nome_pc_remoto\dir_condivisa\file_excel.xlsx") 
fallisce dicendomi che non trova il percorso o il file. 
 
Ma se faccio dir("\\nome_pc_remoto\dir_condivisa\file_excel.xlsx") lo vede
ECCOME, quindi il percorso e' perfettamente valido e accessbile. 
 
Se faccio un altro esperimento, difatti, ossia : 
set EXL = createobject("excel.application") ' apro l' excel in locale
' e poi : 
 
set wb = exl.workbooks.open ("\\nome_pc_remoto\dir_condivisa\file_excel.xlsx")
 
funziona che e' una bellezza. 
 
Il che significa che non mi permette di eseguire METODI sul processo 
excel REMOTO. 
 
Dannazione ! 

 set wb = exl.workbooks.open ("c:\percorso locale della macchina remota\file_excel.xlsx")
 
cambia qualcosa?


Certo. L' EXL ora e' un processo *locale*. Prima invece "viveva" 
sulla macchina remota. 
 


Lo posso dire (aggiungo) perche' col coso la ... come si chiama ...
quello  che  ti  fa vedere i processi attivi per capirci, quando che 
facevo set exl  =  createobject( ..., server)  mi  si "accendeva" un 
excel sulla macchina remota e NON sulla locale.
 
Peccato.
 
immagina di avere un file di 10 milioni di righe. Lo dividi in 1000 
pezzi da 10.000 righe e li mandi pezzo a pezzo sui "millo" pc dell' 
azienda che s' attivano, lo elaborano e te lo restituiscono pronto. 
 
Riduci di UN FATTORE MILLE il tempo di elaborazione. E questa e' solo
UNA applicazione, e la piu' stupida pure. 
 

Mai sentito parlare di DCOM e COM...?
 
@Alex
 

 Mai sentito parlare di DCOM e COM...?
 
E come no, sto parlando proprio di quello :-) 
 
E quindi ?


Hai fatto un'osservazione ovvia... usando DCOM è Lento, usando COM è veloce... è insito nel modello D-COM e COM questa cosa...
 
Ci sono anche altre problematiche legate alla sicurezza usando DCOM, motivo per cui alcune aziende, per Policy, le BLOCCANO.
L'uso di DCOM per questa cosa è assurdo.
 
@Alex

 L'uso di DCOM per questa cosa è assurdo.
 
Ma perche' scusa ? E soprattutto : per *quale* cosa esattamente ?