Newsgroup: it.comp.lang.visual-basic
Titolo: ?Registro oppure File ini

Un programma in una rete, con l'eseguibile nel server.
Ci sono 4 postazioni PC che accedono al programma.
Il programma ha delle impostazioni che devono essere condivise.
Dove le mettereste?
Un file .Ini nel server
Registro di conf. del server
Un DB esistete
Carmelo

 Un DB esistete
No.
Le impostazioni potrebbero essere proprio il percorso del db, user,
password, ecc...
Ciao
Alberto
-- 
Santo cielo, Magnum, si può sapere cos'è questo baccano?
Higgins, posso spiegarle...
Credo non sia necessario.
Zeus, Apollo, a voi...

 Si.
uhm... e se la macchina non sa qual è il server?
in questi casi io metto un file di testo sul client, nella stessa cartella
dell'eseguibile, per le informazioni necessarie al collegamento con il
database, per le altre impostazioni uso un'apposita tabella del db
-- 
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

 Sergio
KillerBoy

 server?
hai ragione, ho letto troppo rapidamente il post iniziale e non ho notato il
particolare.


[KillerBoy = circa_@nospam@@
pippo.it
 in
YAxac.103089$
FJ6.3...@twister1.libero.it
] ha scritto:

Scusa, ma se l'eseguibile dev'essere eseguito dalle postazioni come fanno
queste a non sapere qual è il server? Da qualche parte, qualcosa glielo deve
dire...
Oppure si tratta di un programma (servizio?) che gira solo sul server?

 ha scritto nel messaggio
news:c4ebbd$2hvesk$1...@ID-174464.news.uni-berlin.de...

Scusate, il file .Ini si e il registro no. Perchè?
Visto che l'eseguibile è sul server, e le postazioni Pc lo richiamano da un
collegamento, l'eseguibile non va a leggere le impostazioni dal registro del
server stesso? o sbaglio?
Carmelo

[Carmelo = 
circa_ca...@libero.it
 in
wOyac.103245$
FJ6.3...@twister1.libero.it
] ha scritto:

Sbagli. Un eseguibile (ovunque dislocato) viene eseguito _sulla_ macchina
che lo lancia... Lo stesso viene cercato come file, caricato nella memoria
della macchina richiedente e dalla stessa eseguito.
In ogni caso, anche per accedere al file .INI devi fornire un percorso in
modo che l'EXE (ovunque eseguito) sappia dove andarlo a cercare. Il
registro, invece, sarebbe sempre e solo quello della macchina che vi fa
accesso, ovvero non puoi accedere al registro di un'altra macchina.

 registro del server stesso? o sbaglio?
Solo su sistemi NT, è possibile attivare funzionalità amministrative che
consentono ai client di interagire col registry del server.
E' una cosa, comunque, di una certa complessità sistemistica, quasi
proibitiva da utilizzare da VB.
Nel caso di Terminal Server o Metaframe, il registry è quello del server,
con le diffierenziazioni nei rami HKEY_Current_User e Users.
Escludendo questi due casi molto particolari, basta riflettere su quale CPU
esegue il software...
E' evidente che è il client che esegue, per cui il registry a cui si accede
è quello del client...
Questo aspetto è di fondamentale importanza quando si utilizza Access.
Siccome tutta la logica di blocco, rollback, concorrenza, ecc..., viene
gestita dai provider, e siccome la Cpu è sui client, i provider sono attivi
sui client. Questo fa capire come mai Access in rete sia discretamente
instabile: sono gli stessi client a 'doversi rispettare' e a doversi
'disciplinare'. Se uno crasha, impazzisce, o non è patchato, il db è
direttamente nelle sue mani.
Ciao
Alberto

 ha scritto nel messaggio
news:c4ee25$2hae4i$1...@ID-222113.news.uni-berlin.de...

Quindi mi consigliate un file .Ini, da mettere nella system o nella cartella
dell'eseguibile.
Carmelo

 cartella dell'eseguibile.
Dunque...
Tu hai chiesto una opinione. Noi te l'abbiamo data.
Se la tua richiesta era finalizzata ad un caso reale, devi darci altre
informazioni.
Comunque, nella system non pensarci neppure.
www.sarc.com
 per altre informazioni sul perchč.
Ciao
Alberto

 server stesso? o sbaglio?
Comuque lanciare l'eseguibile *dal* server sui vari client è una pazzia.
Il giorno che dovrai fare delle prove, e quindi ributtare su l'exe ogni 
15 minuti o anche solo inviare l'exe al cliente per aggiornamenti, 
dovrai fermare tutti i terminali che usano il programma.
Finchè sono 2 o 3 te la cavi con una telefonata nei vari reparti, quando 
cominciano ad essere 10 o 20, dovrai scarpinare parecchio, con il 
cliente che ti fiata sul collo perchè stai tenendo fermi tutti.
Ciao

 ha scritto nel messaggio
news:c4eeih$2i2too$2...@ID-184808.news.uni-berlin.de...

Dovrei installare in ogni Pc il programma? questo vuoi dire?
Carmelo

 Dovrei installare in ogni Pc il programma? questo vuoi dire?
Beh, scegli tu ;)
La soluzione ideale è il programma aggiornato sul server.
Sul client ci sarà un programma che controlla se sul server c'è una 
versione più recente di quella in locale.
Se c'è se la copia in locale.
Lancia l'exe in locale.
In questo modo l'exe sul server è sempre libero per eventuali 
aggiornamenti o test.
Ciao

 pazzia.
Ehm... l'eseguibile sta sul server (unica copia fisica) e lui lo lancia dai
client...
Per concludere il mio modo di vedere:
Ogni client deve poter accedere alla cartella (o cartelle/sottocartelle) che
ospita programmi, dati e informazioni varie. Dando per scontato questo (e
non riesco ad immaginare come non lo possa essere), il file .INI (unica
copia sul server) č accessibile ai clients come ogni altra cosa necessaria.

 copia sul server) è accessibile ai clients come ogni altra cosa necessaria.
Forse non hai capito il mio post.
Ciao

[Zanna = 
circa_z...@virgilio.it
 in
c4eeum$2i2too$
3...@ID-184808.news.uni-berlin.de
] ha scritto:

Questa è una (giusta, ma non necessaria) ottimizzazione che però, come ben
evidenziato, crea altri problemi.
Io partirei col server che "serve" e le postazioni non hanno niente sopra
(se non librerie e controlli necessari), ma che conoscono il nome del
server, poi ... si ottimizza.

 Forse non hai capito il mio post.
Credevo. A questo punto ho dei dubbi.

 server, poi ... si ottimizza.
Non sono d'accordo.
Di installazioni ne ho fatte parecchie e di entrambi i tipi, e non c'è 
paragone tra le comodità delle due tipologie.
Non ho più intenzione di farmi i km a piedi solo per cercare e spegnere 
i PC che stanno nell'altro capannone per poter riprovare a fare un 
aggiornamento (e magari nel frattempo ti hanno acceso un PC con il 
programma da un'altra parte)
Ciao

 con il programma da un'altra parte)
Non capisco. A parte OCX e/o DLL, perchè mai un client dovrebbe aver
problemi?
Ripeto: aggiorni solo il server per quell'unico EXE.
Se qualcuno ti avvia l'applicativo in un momento che non deve, gli si taglia
le mani, davanti a tutti.
Ecchecazzo, se va via corrente chi pretende che il PC si accenda?

 server non è generalmente drammatico. E quando è necessario, ci si ferma.
Non so con che tipo di clienti hai a che fare tu :) ma questo tipo di 
aggiornamento comporta due possibili modalità di lavoro:
1) Fermi tutti lo stretto indispensabile per aggiornare il server, 
aggiorni il server, dai il permesso di ripartire (nota: tu non hai 
testato un tubo e rischi che i client si piantano tutti rimanendo 
comunque fermi con il lavoro, ma bloccando anche il tuo exe sul server)
Quest'operazione potrebbe ripetersi per n volte durante una giornata.
2) Fermi tutti per tutto il tempo necessario a provare tutte le tue cose.
Alla fine tutto funzionerà, ma tieni tutti (TUTTI!) bloccati per magari 
anche qualche ora, se non tutta la giornata.
L'(1) sfibra il cliente e ti fa fare la figura dell'incapace.
La (2) fa incazzare il cliente perchè perde una giornata di produzione, 
proprio nel giorno in cui i camio sono fuori che aspettano le bolle 
stampate dal tuo programma! :)
In entrambi i casi rischi come minimo un cazziatone, se il cliente è 
tosto e bast***o anche una bella citazione in giudizio per danni.
Ciao

 cliente che ti fiata sul collo perchč stai tenendo fermi tutti.
Immagina che scarpinata dover copiare il programma su 250 Pc in giro per
l'emilia romagna!
Ho ridotto all'osso la cosa, ma sostanzialmente č cosě.
Noi quando dobbiamo aggiornare siamo dotati di tool (nati, progettati e
programmati dalla mente malata del sottoscritto) che si occupano degli
aggiornamenti durante la notte o la mattina presto, oppure se č un
aggiornamento urgente si manda un fax nei vari stabilimenti, si avvertono i
responsabili dei vari uffici, e se nel giro di mezz'ora non sono usciti
tutti (come accade regolarmente) si va sul server e si comincia a cassare la
gente che tiene aperto i file che devi aggiornare...
-- 
Le persone non sono il proprio comportamento: devi sempre andare oltre,
essere flessibile, capire il punto di vista degli altri, interpretarne i
comportamenti ed intuirne le esigenze.
Per rispondere in privato elimina
dall'indirizzo "togliquesto"
MasterDavidex
David Ruscelli

 tosto e bast***o anche una bella citazione in giudizio per danni.
Maperpiacere... ;-)
Una volta si diceva "è arrivato il programmatore" e tutti si fermavano e ti
offrivano il caffè.
Ora la stessa cosa, ma non è detto che si fermino. Il primo, pur essendo
avvertito di star fermo sino a nuovo avviso, che riceve un errore 429, se ne
guarda bene dal dirlo...

 Ecchecazzo, se va via corrente chi pretende che il PC si accenda?
A parte che tagliargli le mani non serve a niente se non a passare per uno
stronzo senza un minimo di umanità (parlo per esperienza personale) basta
aprire il server manager di windows e seccare gli utenti che tengono aperti
'sti minchia di file!


 utenti che tengono aperti 'sti minchia di file!
Olà, Frank, io lo dicevo in modo figurato, ma tu, usando SM, lo fai per
davvero, pur sempre virtualmente. No?!

 gente che tiene aperto i file che devi aggiornare...
E ti pare un bel sistema?
Magari qualcuno di quelli stava facendo qualcosa di urgente.
Boh, io non capisco... sarò cretino io a farmi dei problemi.
Ciao

 aggiornamento comporta due possibili modalità di lavoro:
[cut]
Noi sviluppiamo una bella fetta di roba come servizi NT, per cui non abbiamo
problemi di questo tipo (gli aggiornamenti li fa l'administrator arrestando
il servizio e riavviandolo sulla singola macchina server).
L'altra fetta di applicativi, quelli che possiamo in qualche modo chiamare
'gestionali', e che non seguo direttamente, li facciamo girare dentro IE.
Se l'aggiornamento è possibile 'a caldo', perchè il DB non è cambiato e non
ci sono stati intermedi critici, basta un xcopy dei nuovi file all'interno
della cartella di IIS sul server (i file esistenti non sono ovviamente
bloccati da nessuno, visto che IIS lavora in sola lettura). Appena un utente
cambia schermata, viene avvertito da IE che c'è una nuova versione, e gli
viene chiesto di accettare tale nuova versione. Se non accetta, IE va su una
pagina blank e scarica dalla memoria l'applicativo. Se accetta, la pagina
che gli appare apparterrà al nuovo applicativo.
Se il db è stato modificato, o se la transizione 'a caldo' può comportare
problemi, si nega l'accesso al db per il tempo della modifica. Durante tale
periodo, tutti i client connessi segnaleranno la mancanza di connessione al
db, e gli operatori in genere chiudono l'applicativo e riprovano dopo.
Se la cosa è ancora più critica, si sostituisce la splash di avvio in IIS
con una banale pagina html "manutenzione in corso", e si lavora
indisturbati, anche se qualche utente tentasse di avviare il client.
Per le prove, in genere basta avere due siti distinti, uno di test e uno di
produzione. Fatta la copia dei nuovi file sul server (sito di prova), si
prova tutto con l'url apposito, e quando si è tranquilli si spostano i file
nel sito di produzione.
Restando in tema di exe, il grosso vantaggio della soluzione del bat o exe
che fa una copia sul client all'avvio del software, è la possibilità di
lavorare disconnessi in caso il server sia giù (purchè lo stesso server non
sia anche db-server, nel qual caso...).
Ciao
Alberto

 loro archivi.
Ripeto, non so che clienti e che prodotti hai.
Noi siamo una ventina di programmatori e facciamo 2/3/4 aggiornamenti 
alla settimana da una decina d'anni.
Non ricordo una (UNA) sola volta che tutto sia filato liscio.
Saremo una ditta di incapaci :)
(alcuni sě... ma questo č un altro discorso :PPP)
Ciao

 2) Fermi tutti per tutto il tempo necessario a provare tutte le tue cose.


 aggiornare...
Ma cosa intendi per 'tiene aperto i file che devi aggiornare'?
E' un concetto che mi suona strano.
O i client sono indipendenti, e possono lavorare disconnessi (quindi non hai
file loccati), o la distribuzione deve avvenire in sola lettura (e quindi
non hai file loccati).
Ciao
Alberto

 davvero, pur sempre virtualmente. No?!
Avevo capito che tu per "tagliargli le mani" intendessi cazziarli
pesantemente in pubblico, per quanto riguarda il SM sì, è così.


 (alcuni sì... ma questo è un altro discorso :PPP)
Boh, Zanna, lungi da me dal fare affermazioni del genere. Anche a me capita
di andare dal cliente e una certa cosa non va, ma sono situazioni rare, solo
perchè non provate con le 8000 opzioni precise a quelle che ha l'utente. Non
mi è mai capitato di tener fermo un utente. Al limite quel che consegno di
nuovo va ... a metà. Se proprio accade di creare situazioni di blocco,
correggo, ricompilo sul portatile e installo l'EXE corretto. In casa
dell'utente. Ma, ripeto, è successo così raramente da non ricordarmene.

 mai avuti.
E come fai se hai anche una decina di activeX referenziati?
Testi il programma con i files di testi (anch'essi una copia degli 
originali) e poi ti preoccupi di riallegare ad ogni compilazione quelli 
giusti?
Senza contare che anche se con nomi diversi le classi vengono registrate 
secondo il loro nome e non secondo il nome del file contenuto.
I casini infiniti che derivano da questo non te li sto nemmeno a elencare :)
Ciao

[Zanna = 
circa_z...@virgilio.it
 in
c4egqn$2i2too$
8...@ID-184808.news.uni-berlin.de
] ha scritto:

No, Zanna, cerchiamo di capirci: la "violenza" (pur con ultimatum a tempo)
esemplificata da Frank non piace nemmeno a me (proprio perchè uno può e deve
finire qualcosa), ma quello che tu, convenientemente, hai fatto non è per
nulla disprezzabile. Però, permettimi, hai dovuto creare tutto l'ambaradan
perchè la gestione e l'adeguamento fossero gestiti in modo automatico, non
in manuale.
La prima versione del tuo programma già lo faceva?
Se no, ecco, ci intendiamo. Se sì, beh, che dire, complimenti.

 Boh, io non capisco... sarò cretino io a farmi dei problemi.
Gli hai mandato un fax! Gli hai telefonato! Gli hai dato mezz'ora di tempo
per finire i lavori in sospeso!
Cosa gli devi dare! un premio? dei soldi? gli devi dire che se escono
tromberanno come dei ricci per il resto della loro vita?
Per quanto riguarda il tempo di fermo varia dai 30 secondi se sono usciti
tutti ai 5 minuti se c'è qualcuno da cassare, mi pare un tempo
accettabilissimo.


 correggo, ricompilo sul portatile e installo l'EXE corretto. 
E come fai se questo è loccato? :)
Forse dipende dal tipo di app.
Noi facciamo app. che girano dal bordo macchina all'ufficio per la 
pianificazione della produzione alle stampe delle bolle... non capita 
mai che durante i test "fatti in casa" tu possa vedere tutte le 
condizioni _reali_ con i dati di produzione.
Ad. es. pianificare la prduzione occorre tener conto di mille cose, 
dalla disponibilità a magazzino di prodotti che possono o meno essere 
combinati tra loro alla capacità produttiva della macchina al tempo 
richiesto per l'evasione dei vari ordini... succede spessisimo che 
qualcosa nel lato pratico non quadra in tutta la catena e quindi devi 
rivedere alcuni punti, e questi li puoi vedere solo dal cliente.
Ciao

 Testi il programma con i files di testi (anch'essi una copia degli


 pesantemente in pubblico
Se lo vengo a sapere (e se so con certezza che sono stati avvertiti), sì, li
cazzio in pubblico.
Ehm... più spesso accade che, invece, il programmatore arriva, chiede di
uscire dall'applicativo, alcuni escono e, nell'attesa dell'ultimo, quello
che era già uscito dice "devo fare una bolla!".
Che fai? Io lo guardo e, senza parlare gli faccio capire che ho capito che
voleva farsi bello (anzi, indispensabile) davanti al capo presente, ma che
quella bolla l'avrebbe fatta forse fra un'ora se non ci fossi stato io...
A volte mi faccio pagare a tempo e allora posso stare zitto, altre a forfait
e allora mi alzo e ripeto "uscite dall'applicativo, per favore".
Ahhhh, non siamo più i "programmatori" di una volta... ;-)

 non hai file loccati).
Se su un server hai un eseguibile e un client te lo sta tenendo aperto non
lo puoi aggiornare, l'errore è.
"Impossibile copiare, file già in uso da un altro utente o programma"


 rivedere alcuni punti, e questi li puoi vedere solo dal cliente.
Capisco (e conosco) la complessità, ma non sono d'accordo che queste cose
debbano essere viste solo dal cliente, proprio perchè arzigogolate.
L'analisi di una modifica dovrebbe essere, per quanto sia la modifica
complessa, il più possibile chiara, quindi simulabile in fase di test, in
casa. Ovvio, dal cliente possono saltar fuori altre cosine, se ne deve
prendere atto, magari confrontando con quanto prima stabilito. Un'altra
integrazione? Bene. Ci siamo male intesi? Bene. Fatto sta che "l'abbiamo
fatto così, perchè così l'avevamo inteso". Faremo le modifiche del caso.
Ovvio che stiamo generalizzando. A volte (ma a volte!) capita che le cose
non vadano liscie, più raramente è accettabile che quel che s'è fatto
impedisca di continuare a lavorare, al limite nelle condizioni di prima...

 cazzio in pubblico.
Una volta lo facevo anche io, ma oltre a non servire a niente, con i miei
utenti, dopo un po' ero diventato "lo stronzo senza un minimo di umanità".
Così ho smesso di incazzarmi, o almeno ho cercato di incazzarmi di meno,
anche perchè a volte perdi la pazienza e basta, mica lo fai apposta!
Ora li casso in silenzio e basta, se chiamano per lamentarsi gli spiego con
calma che dovevo aggiornare e che ora è tutto a posto.
Della serie vivi e lascia vivere...
Ora sono solo quello che ogni tanto viene a lavorare con le palle girate...
Va beh...
stendiamo un velo peloso...


 "Impossibile copiare, file già in uso da un altro utente o programma"
Si, appunto.
E' un discorso che capisco da parte di Carmelo, che da niubbo sta
sperimentando.
Ma quando si parla di roba in produzione, pensare che un client possa tenere
una qualunque cosa 'bloccata' su un server è terrorizzante.
I crash di rete sono tutt'altro che impossibili, e un sistema deve essere
libero di riavviarsi, ripristinarsi, resettarsi, e bla bla bla, tutte le
volte che vuole.
Quella degli eseguibili sul server mi sembra un lavoro senza ragione di
esistere.
Però, ad ognuno la libertà di agire come ritiene meglio.
Ciao
Alberto

 fatto così, perchè così l'avevamo inteso". Faremo le modifiche del caso.
Ma a te non capita mai di gestire male un SetFocus, sbagliare la 
variabile da sommare o cavolate del genere e di non accorgertene, perchè 
magari i dati che usi per puro caso non ti generano errori o problemi 
visibili?
Oppure che c'è una condizione che nessuno ha considerato nell'analisi 
che però è indispensabile correggere e che tutto sommato è una cavolata 
da correggere?
Se non ti succede mai sei un ottimo debugger, oppure tutti noi siamo dei 
pessimi debugger, perchè queste cose sono all'ordine del giorno.
E se sei dal cliente e lui ti chiede cha la scritta la vuole in rosso 
anzichè in blu tu fai un preventivo e gli dici che lo metterai a posto 
per la prossima volta?
E se poi quando la vede rossa decide che però si vede poco e che è 
meglio metterla in grassetto?
Noi dai clienti non sucede mai (ma MAI) che si copia il programma e 
tutto funzioni.
I casi di ricompilazioni sono tanti.
A me è capitato di ricompilare una ventina di volte in un solo giorno 
mentre ero in trasferta, e di solito ci si aggira intorno alle 3 
compilazioni per intervento.
Ciao

 compilazioni per intervento.
Ma perchè?, nei tuoi panni, mi chiederei...
Scripa manent ...

 Ma perchè?, nei tuoi panni, mi chiederei...
Evidentemente lavoriamo in campi con problematiche completamente differenti.
Ciao

 differenti.
Probabile, ma volevo solo dire "se l'analisi, ascoltata, scritta, inviata e
approvata è chiara, sarà chiaro anche quel che si deve fare,
riprodurre/simulare e testare".

 riprodurre/simulare e testare".
Sono sempre più convinto che lavoriamo in settori troppo diversi.
Anche a me piacerebbe fare tutto a casa e mandare il file via e-mail.
E spesso faccio così, ma per correggere problemi minimi.
Per tutti gli altri è quasi sempre necessario andare dal cliente.
Oggi sono 15 giorni che sto provando un prog. che doveva essere pronto 
la settimana scorsa.
Ora è quasi pronto, ma sono convinto al 101% che portato dal cliente ci 
sarà qualcosa da sistemare.
Ciao

 ci sarà qualcosa da sistemare.
Se è complicato è possibile, ma non ne farei un problema, fa parte delle
eccezioni.

 ci sarà qualcosa da sistemare.
Voglio precisare, perchè son convinto che questo sia il punto delle "nostre
incomprensioni":
Se c'è qualche piccolo errore, ok. Si decide dove e quando sistemarlo.
Se c'è qualche grosso errore, non ok, evidentemente il test non è stato
adeguato, ma, l'abbiamo detto, anche questo può accadere. Sono quelle che io
definisco "eccezioni".
Se il cliente dice "tutto ok, ma vorrei anche questo" allora il discorso è
diverso, molto.
Mi sono spiegato?

 eccezioni.
Di eccezioni stai tranquillo che ne verranno fuori una valanga :)
Magari continueremo la discussione al meeting ;)
Ciao

 diverso, molto.
Sì, chiaro, ma io mi riferisco sempre al problema originale: non tenere 
il prog. bloccato sul server perchè servirà sicuramente lavorarci sopra.
Ciao


wrote:


le testa e le critica....
Gesu', cosa mi hai fatto ricordare!!
Stiamo parlando della notte dei tempi, intorno al 1990. All'epoca
lavoravo per una software house che si occupava di grafica
industriale, e in particolare facevo perte del gruppo di elaborazione
immagini per la stamperia tessile e la fotoincisoria.
I responsabili del gruppo decidono, sulla spinta dei clienti, di
creare una nuova release del prodotto di punta che incorporasse tutti
i suggerimenti dei clienti e alcuni che avevamo suggerito noi sulla
base dell'esperienza presso i clienti.
Al lavoro di sviluppo, durato 2 mesi (per 4 persone), e' seguita una
fase di test interna per un altro mese: i responsabili del gruppo a
turno testavano giochicchiavano col prodotto, testavano le soluzioni e
segnalavano i bugs.
Non contenti, abbiamo chiesto la collaborazione di 3 ditte clienti e
abbiamo usato loro come beta testers, in modo da avere una prova del
prodotto sul campo. Un bell'impegno, dal momento che non c'era
internet e la possibilita' di sparare aggiornamenti...
Bene, dopo due mesi di beta test il prodotto non sembrava piu' dare
difficoltà, si decide il rilascio del prodotto. 
In capo a un altro mese avevamo due pagine di word contenenti
segnalazioni di bugs da risolvere........
:))))
Ciao!
Luca