Newsgroup: it.comp.lang.vo-clipper
Titolo: cerco un parere: archivi enormi - tanti client

Ciao a tutti,
mi trovo a che fare con un applicativo Clipper (5.2c) utilizzato per gestire 
pianificazione-produzione-magazzini-contabilità di due impianti industriali 
abbastanza grandi (circa 250 dipendenti).
Poco più di 130 client insistono sugli stessi archivi (300 dbf con 3-4 
indici ntx ciascuno) di dimensioni ormai fuori controllo: alcuni archivi 
sono ben oltre i 500Mbyte) che risisedono su un file sever Novell.
E nella migliore tradizione non esiste una straccio di documentazione se non 
il codice stesso (circa 230.000 linee).
Vi chiedo se potete aiutarmi a trovare informazioni relative
-alle dimensioni delle tabelle DBF gestibili da Clipper
-all'accesso concorrente di DBF su file server da parte di clipper
-alla possibilità di passare il file server da Novell (3.12) a windows
grazie in anticipo per qualunque aiuto,
Stefano


Per prima cosa ti consiglio assolutamente di provare a ricompilare con
xHarbour (
www.xharbour.org
). Recentemente ne sono stati ampliati i
limiti grazie all'uso delle API del sistema operativo ospite.
Subito dopo ti consiglio un altro passo indispensabile: utilizzare
DBFCDX al posto di DBFNTX. Il passaggio dovrebbe essere totalmente
indolore.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg



A parte i consigli di EMG, in particolare riguardo al passaggio
NTX->CDX, che ti consentirebbe di diminuire drasticamente il numero di
handle utilizzati, ti consiglio anche di dare un'occhiata a ADS, costa
qualche Euro ma li vale tutti.
---
ciao, acc(at)
libero.it

 qualche Euro ma li vale tutti.
Veramente costa un po' di più di qualche Euro e per di più devi pagare
per ogni postazione (se non sbaglio). Inoltre rispetto al DBFCDX ha
pesanti limitazioni sull'utilizzo di funzioni utente nell'espressione
chiave e nella condizione FOR degli indici. Se uno è abituato ad usare
queste cose parecchio, ci si trova male.


 -alla possibilità di passare il file server da Novell (3.12) a windows
Passare da Novell a Windows ?????????
Ti hanno esplicitamente richiesto di peggiorare l'affidabilita' del  
sistema ? :)))
Ciao.alberto.
-- 
===============================================================
Alberto Rubinelli - A2 SISTEMI  Opera 7.54->
news.individual.net
Via Costantino Perazzi 22 - 28100 NOVARA - ITALY
Tel 0321 640149  Fax 0321 391769 BBS 0321 392320
Mail: 
alb...@retrocomputing.net
  ICQ : 49872318
Visita il mio museo di computers: 
http://www.oldcomputers.it
---------------------------------------------------------------
Per favore, non scrivetemi in html, testo ascii a 7 bit
Non rispondo a chi mi scrive con indirizzo di reply alterato
===============================================================

queste cose parecchio, ci si trova male.
Le limitazioni non sono "pesanti", in compenso offre parecchie
caratteristiche interessanti (se uno ha voglia di implementarle) che
portano le prestazioni del sistema a livelli impensabili (rispetto
all'adozione del solo RDD CDX).
---
ciao, acc(at)
libero.it

 all'adozione del solo RDD CDX).
Vero, magari sara' che sono abituato a lavorare in modo piuttosto  
semplice, ma non ho trovato grossi limiti.
Le prestazioni in alcuni casi balzano veramente.
Io lo uso su server Netware, qualcuno lo usa su linux ? la maggior parte  
penso lo usino su win32
Ciao.Alberto.


 Le limitazioni non sono "pesanti",
Be', non si possono utilizzare le funzioni utente e solo alcune funzioni
del Clipper sono supportate. Per me questa è una limitazione
pesantissima che mi costringerebbe non solo a riscrivere le applicazioni
ma a cambiare completamente filosofia tornando indietro rispetto
all'interattività spinta che oggi viene richiesta dagli applicativi.


 penso lo usino su win32
Su Linux non esiste proprio il problema di utilizzare sistemi
client/server dato che la rete funziona in application sharing.


 faticaccia :))
Sarà faticoso (non ne dubito!) ma è secondo me un'ottima cosa.
Complimenti.


 client/server dato che la rete funziona in application sharing.
Io intendevo server linux e macchine win32, in tal caso faccio eseguire il  
lavoro al server linux.
Oppure non ho capito nulla di cosa hai detto :)


Ciao,
i problemi reali sono
- sparizione di record: in transazioni cjhe aggiornano record multipli 
*ogni tanto* alcuni archivi vengono aggiornati e altri no (numero di 
client? carico di rete?)
- il *corporate IT boss* (è canadese per cui fate voi il peso che posso 
avere nella decisione) ha decretato il passaggio da novell a 
windows...entro un mese.
Io e il mio collega Alberto siamo, come si dice in gergo, programmatori 
stagionati (Alberto in clipper anche) ma non abbiamo il tempo per 
scavare e modificare radicalmente il codice cosi stiamo cercando 
consigli/workaround per interventi che possano aiutarci a minimizzare la 
sparizione dei record e la migrazione a win32.
Tenete presente che noi non siamo i programmatori originali e abbiamo 
ricevuto il *pacco* due mesi fa e l'eredità comprende ZERO 
documentazione, ZERO possibilità di supporto.
In ogni caso per il cambio degli indici (su cui stavamo ragionando) e la 
migrazione posso chiedere se qualcuno di voi è interessato? (ho del 
budget a disposizione e posso spenderlo)
Grazie,
Stefano


 Oppure non ho capito nulla di cosa hai detto :)
Mi spiego: normalmente i server Linux funzionano in application sharing.
Quindi sia l'applicazione che i dati risiedono sul server. Ma a
differenza del file sharing l'applicazione viene eseguita sul server
stesso, non sul client, e al client arrivano solo le videate.


 stesso, non sul client, e al client arrivano solo le videate.
Ok, chiaro, in questo caso non ha senso, come dici tu.
In pratica il mio utilizzo invece e' come database server, cioe'  
applicazione in ambiente win32 e database server linux/netware/win32(bleah)
Ultimamente sto cercando di rendere le applicazioni che scrivo  
indipendenti dal database, ad esempio sul gestionale puoi scegliere BDE  
della borland, ADS, Access oppure MySQL ... solo che madonna che  
faticaccia :))
Ciao.Alberto.


 budget a disposizione e posso spenderlo)
Penso che qui tutti siamo interessatissimi :))))


 budget a disposizione e posso spenderlo)
Io potrei esserlo. Magari scrivimi in privato le condizioni.


 migliorare la sicurezza in rete dell'RDD DBFCDX.
Devo decidermi a farlo anche io, almeno riutilizzo le vecchie  
applicazioni, molte hanno ancora il loro mercato. Per quelle nuove ormai  
sono passato a Delphi gia' da anni.
Tu che lavori gia' con xharbour da un po, lo reputi maturo per un impiego  
in produzione ?
Ciao.Alberto.


 in produzione ?
Assolutamente sě. Lo uso "in produzione" (che termine arcaico :-) )
ormai da un anno e gli unici problemi che ho avuto sono derivati dal
fatto di utilizzare la versione del CVS (instabile) invece che quella di
www.xharbour.org
 (stabile).


 
www.xharbour.org
 (stabile).
non mi azzardero ' oltre la stabile. Almeno rimetto in pista il mio  
vecchio case che con il clipper mi aveva dato tante soddisfazioni (e me ne  
da tuttora).
faccio una domanda forse idiota: ma da xharbour, posso chiamare una  
funzione in una dll, ovviamente niente di grafica ?


 funzione in una dll, ovviamente niente di grafica ?
Certamente. Ma in xHarbour nudo e crudo devi utilizzare un wrapper C
(che puoi mettere anche nello stesso PRG). Esempio banale:
FUNCTION MAIN()
    SHELLEXECUTE( 0, 0, ".", 0, 0, 1 );
    RETURN NIL
#pragma BEGINDUMP
#include "windows.h"
#include "hbapi.h"
HB_FUNC( SHELLEXECUTE )
{
    hb_retnl( ( LONG ) ShellExecute( ( HWND ) hb_parnl( 1 ), hb_parc( 2
), hb_parc( 3 ), hb_parc( 4 ), hb_parc( 5 ), hb_parni( 6 ) ) );
}
#pragma ENDDUMP


 funzione in una dll, ovviamente niente di grafica ?
Dimenticavo: ovviamente se la funzione è in una DLL devi utilizzare le
solite LoadLibrary()/GetProcAddress()/FreeLibrary().


 (che puoi mettere anche nello stesso PRG). Esempio banale:
Sei stato chiarissimo, grazie!
Mi si apre un mondo di possibilita' :) ed anche di qualche nottata a  
debuggare :))


 debuggare :))
:-)))


all'interattività spinta che oggi viene richiesta dagli applicativi.
Qualche limitazione c'e', ma dire che supporta "solo alcune funzioni"
mi sembra esagerato, io piuttosto direi che "solo alcune funzioni" non
sono supportate, c'e' una sottile differenza.  ;-)
Sono d'accordo sul fatto che portare applicazioni su ADS, puo' essere
difficoltoso, se queste utilizzano abbondantemente funzioni che non
sono supportate.  Ma dipende dai casi, personalmente lo sto facendo e
non trovo difficolta'.
ADS e' uno strumento costoso che trova giustificazione in certi
ambiti, non ha senso utilizzarlo dove le sue prestazioni non sono
richieste, su questo credo siamo d'accordo.
In applicazioni che siano veramente "client/server", non vedo altri
prodotti che offrano caratteristiche e prestazioni paragonabili.
---
ciao, acc(at)
libero.it

funzione in una dll, ovviamente niente di grafica ?
Fra tutti i 'discendenti' di Clipper, xHarbour e' sicuramente quello
messo meglio in quanto a interazione con le DLL (e con l'OS in
generale).  IMHO questa caratteristica e' attualmente poco sfruttata,
ma in futuro puo' portare sviluppi molto interessanti.
Per qualche motivo che non so spiegarmi VO e xBase hanno pesanti
limitazioni in questo senso (C3 nin zo'!).
---
ciao, acc(at)
libero.it

Passare da Novell a Windows ?????????
Vuoi mettere, ha il lock ottimistico!
L'ottimismo e' il profumo della vita....
Ok, scherzavo ;-)
---
ciao, acc(at)
libero.it

budget a disposizione e posso spenderlo)
Le offerte di lavoro sono sempre benvenute su questo NG!
---
ciao, acc(at)
libero.it

 sono supportate, c'e' una sottile differenza.  ;-)
Vuoi dire che posso utilizzare una mia funzione comunque definita come
chiave dell'indice o come espressione FOR? Mi piacerebbe molto che fosse
così ma non credo. Controlla bene e fammi sapere.


 limitazioni in questo senso (C3 nin zo'!).
Sei sicuro? Che tipo di limitazioni?


 Vuoi mettere, ha il lock ottimistico!
Opportunistico, che è ben diverso anche in contesti diversi
dall'informatica. :-)


ciao,
grazie a tutti per le informazioni che mi passate e che pian piano 
verifico. Dopo un paio di giorni immersi nel mare di quelle centinaia di 
migliaia di righe di codice per controllare varie cose il nostro collega 
sistemista ci fa gentilemente notare che parte dei client che hanno qua 
usano IPX e parte IP con una distribuzione divertentemente casuale.
Mi viene il sospetto che le 'sparizioni' (record che dovrebbero esserci 
per forza ma che non ci sono) possano dipendere da strani 
agggrovigliamenti tra i protocolli.
Ho chiesto di uniformarli tutti.
Il passaggo da novell a win è un decreto corporate perchè solo nella 
'provincia dell'impero' in cui lavoro attualemente sono rimasti tre 
server novell: non ci sono santi devono sparire e con esso anche IPX (eh 
si: gli strumenti di net management corporate ....non lo prevedono).
Da quello che dite ho capito che il passaggio a M$ potrebbe essere 
critico ma s'ha da fare.
Noi siamo a nord di Monza, provincia di Lecco (praticamente ad inculonia 
data la reale posizione), vista la disponibilità che qualcuno di voi ha 
manifestato, se siete ancora interessati a darmi supporto almeno per il 
passaggio a win (che devo fare) entro un mese contattatemi all'indirizzo 
privato cosi smetto di disturbare sul forum pubblico anche se spero di 
aver dato argomenti di discussione interessanti.
grazie,
ciao

 aver dato argomenti di discussione interessanti.
Naturalmente la disponibilità non è di partire per inculonia. :-))))) Se
la cosa si può fare via email bene altrimenti non posso aiutarti.


cosě ma non credo. Controlla bene e fammi sapere.
Assolutamente NO!
Quando parlavo di "funzioni utilizzabili" mi riferivo a quelle della
libreria standard di Clipper.
---
ciao, acc(at)
libero.it

per forza ma solo quando, appunto, hai una DLL esterna da utilizzare.
Non c'e' molto software a questo proposito, ad esempio gia' menzionare
GUI sotto xHarbour sembra di parlare arabo (mi riferisco alla versione
gratuita).  Le GUI gratuite che ho visto non sono un gran che, inoltre
sono stranamente bloccate (sviluppo) da oltre un anno.
Secondo me l'abbondanza di librerie (GUI e non) non puo' fare che bene
a xHarbour, lo stesso e' avvenuto per Clipper, ma forse e' soltanto
questione di tempo.
---
ciao, acc(at)
libero.it

dall'informatica. :-)
Alla luce delle conseguenze provocate da questa bella innovazione, io
l'ho ribattezzato cosi'!
---
ciao, acc(at)
libero.it

stesso, non sul client, e al client arrivano solo le videate.
Questo si puo' fare anche con windows, ma... non e' proprio il massimo
in termini di prestazioni, ne' con windows ne' con *nix.
Era un sistema molto utilizzato negli anni 80, oggi qualsiasi client
e' dotato di sufficiente cpu e memoria per far girare un applicativo.
In ogni caso e' possibile utilizzare un modello client/server anche
con *nix, e se ben fatto e' utilizzabile anche se i client hanno un
sistema operativo diverso.
---
ciao, acc(at)
libero.it

 questione di tempo.
Sono d'accordo. Le potenzialitŕ sono infinite.


 l'ho ribattezzato cosi'!
Giusto! :-) Comunque il lock ottimistico/pessimistico già esiste in
Visual Basic ed è tutt'altra cosa.


Ciao a tutti,
aggiungo un paio di informazioni:
quando parte l'applicazione apre (e tiene aperti) una quarantina di dbf
-non fa uso di commit
-non fa uso di funzioni particolari legate a novell
-non si intende modificare l'interfaccia (rimane questa)
ciao
"acc" <unk...@fake.address> ha scritto nel messaggio 
news:3eu411pl3d3r8gl30...@4ax.com...


 ha scritto nel 
messaggio news:42150925...@emagsoftware.it...


 -non si intende modificare l'interfaccia (rimane questa)
Allora la ricompilazione con xHarbour è d'obbligo. :-)


 ho forse tutte le informazioni,
Il lock ottimistico/pessimistico del Visual Basic significa che la
durata del lock sulla pagina (Visual Basic fa il lock a pagine non a
records) è, rispettivamente, solo durante l'update dal buffer al disco
(ottimistico) oppure dalla prima modifica di un campo fino all'update
stesso (pessimistico). La modifica si può paragonare ad una REPLACE del
Clipper e l'update ad una COMMIT.
L'opportunistic locking invece è una tecnica utilizzata da Windows
NT/2000/XP (non sono sicurissimo del primo) per ottimizzare le
prestazioni del file sharing nella sua rete peer-to-peer ma in realtà ha
causato più guai che miglioramenti.



http://www.xharbour.org/index.asp?page=product/thirdparty
Io avevo visto What32 e MiniGUI, le altre non le conoscevo.
MiniGUI di fatto si appoggia su What32 per le API, quest'ultima che
fine ha fatto?
Ho dato un'occhiata (un po' di fretta) alla documentazione di HwGUI,
mi sembra buona.
---
ciao, acc(at)
libero.it

 fine ha fatto?
E' nella directory contrib del CVS di xHarbour. L'ultimo changelog è del
14/12/2004. L'ultima stable release la puoi trovare a questo indirizzo,
nei pacchetti contribution:
http://www.xharbour.org/index.asp?page=download/windows/binaries_win
