Newsgroup: it.comp.appl.access
Titolo: Errore Libreria  Jet and Replication Ob. 2.1

Salve.
Un libro mi indica di istallare questa libreria:
"Microsoft Jet and Replication Objects 2.1 Library"
per connettere il mio DB  con un DB access esterno.
Nel mio sistema operativo Win7 Access 2010,
quando provo a caricarla mi restituisce:
"errore di caricamento DLL"
... sapete a cosa è dovuto?
Ed è indispensabile per fare questa operazione?
 
 


...P.s
Infatti l'errore parte sin dalla prima riga di codice
Dim ApriExt As New Connection
New è in azzurro: la riconosce ma poi mi dà
"Utilizzo non valido della parola chiave NEW"
Cominciamo bene....


Peccato che qui non si possano pubblicare screenshot:
Le librerie attualmente caricate sono:
 
1)Visual basic for application
2)Microsoft Access 14.0 object Library
3)OLE Automation
4)Microsoft ADO Ext. 2.8 for DLL and Security
5)Microsoft Office 14.0 Access database engine Objects  Library
6)Microsoft ActiveX Data Objects 2.1 Library
 
 
 
 

Puoi spiegare tecnicamente PERCHE' devi usare questa LIB che viene chiamata JRO...?
Che tipo di utilizzo devi fare...?
 
Di solito si usa per il COMPACT quando si usa ADO in quanto ADO non espone metodi per il Compact...!
Tu con Access usi DAO che è NATIVO, spero per te,... quindi ripeto la domanda... 
 
PERCHE'...?
 
P.S. dall'elenco delle LIB, dovresti invertire la 4 e la 5... prima ACEDAO, poi ADO... 
 
ADO si può usare, ma se c'è un motivo sensato... e di solito con Access-JET non c'è.
 
Se hai lato SERVER un RDBMS può servire... ma siccome si usano le LINKED TABLE, via ODBC...
 
Insomma, c'è qualche nuvola di confusione.
 
@Alex

Ti sbagli di grosso Alex. Non c'è qualche nuvola di confusione, cammino nella nebbia senza fendinebbia.
Sto provando per la prima volta a collegarmi con db esterno, per necessità. Il libro dalla quale sto prendendo la routine di esempio mi ha indicato la libreria che ho caricato. Ma come al solito non funziona niente, sin dalla prima riga. Io si, solitamente uso Dao. (Anche se anni fa usavo Adodb per aprire recordset... ma poi ho capito che non serviva e son tornato a Dao.) Ora mi serve connettermi ... qual è l'abc? 

Si usano le LINKED TABLE...!
Una volta LINKATE le Tabelle, lavori come in locale con DAO.
 
Per linkare le tabelle puoi vedere questo:
https://www.addintools.com/documents/access/where-is-linked-table-manager.html
 
 
P.S. JRO non serve per fare connessioni... eventualmente puoi usare ADO via OLEDB.PROVIDER.
 
Servirebbe un manualetto per queste cose.
 
@Alex

Ma io uso già tabelle collegate, praticamente sempre, per poter fare modifiche al Fe senza toccare il be. In questo caso pero vorrei evitare questo sistema in quanto due db sono identici, stesse tabelle, stesso Fe. Quindi andrebbero riscritte tutte le routine in modo da far funzionare tutto coi nuovi nomi. 
Anagrafica si chiamerebbe Anagrafica1
Clienti si chiamerebbe Clienti1 etc....
Tu dirai ma a che serve tutto questo?
Il cliente oltre che in ufficio lavora in giro e quindi deve usare lo stesso db. Ma quando torna in ufficio deve aggiornare le tabelle coi nuovi dati da accodare alle tabelle del db in ufficio. Quindi volevo andare a prendere i dati indirizzando ado su un certo percorso. Data source c:\utenti etc.....
Cmq... qual è la soluzione migliore secondo te? Quella più approdabile...

Aspetta no! Ho scritto una grande cazzata. Di quelle che restano per saecula e saeculorum su Google:-)
E' il db principale che le rinomina cosi una volta collegate ma nel db di origine rimangono coi loro nomi !!!.... 


".. e quindi deve usare lo stesso db.."
L'hai detto tu quello che devi fare
Fallo lavorare sui dati che ha in ufficio
Via terminal server e' la via piu' semplice
Tenere dei doppioni e' estremamente complesso
E pure inutile aggiungo io a meno che non ci siano ragioni particolari 
per mantenere i due db separati

Il 24/05/2019 14:32, 
gabria...@gmail.com
 ha scritto:

mi permetto...
fare il sincro è una gran rogna da gestire e ti consiglio di evitarla se 
le tabelle da tenere sincronizzate sono molte
 
quando il tuo cliente è fuori ufficio, in ufficio usano il db?
se no, potresti fargli copiare l'mdb dei dati dal pc al portalile e 
viceversa al ritorno in ufficio. Ci sono programmi free che fanno il sincro.
 
se invece in ufficio lo usano quando lui è fuori, non fai prima a farlo 
lavorare tramite rdp direttamente sulla postazione in ufficio da remoto?
 
altra soluzione, prendi un pc con 2gb di ram, 30 gb di disco in cloud su 
aruba, installi il tuo programma e il cliente lo puo usare da qualsiasi 
dispositivo e da qualsiasi parte del mondo sempre in rdp. Hanno piani a 
consumo e a costo fisso. Te la cavi con 30 euro al mese per il costo 
fisso, meno se non gli serve averlo 24h al giorno acceso
 
ciao
BFS
 

Al clouds ci avevo pensato ma non l'ho mai fatto. E poi c'e un prpblema. Lo costringo ad avere una connessione. Se non c'è campo niente.... non si lavora! Improponibile. 
Forse dovrei approfondire il concetto di syncro. Che fanno sti programmi, rispetto a ciò che si fa manualmente? Cioe copia e incolla? In ufficio non lavora nessuno. A fine ricezione dei suoi clienti dovrebbe ricordare di fare il back up dei dati sul portatile e viceversa. Che fanno i sincro?

 
 
temevo il discorso del "non c'è campo", ho dovuto affrontarlo anche io 
per agenti che raccolgono ordini e li devono trasmettere in sede
 
per il sincro vedi questo, funziona bene ed è free
https://freefilesync.org/
 
 
lo imposti che tenga sincronizzata cartella del notebook e quella del pc 
che contengono i due BE e con un click il file più recente sovrascrive 
l'altro
 
ciao
BFS


Ho un dubbio...
 
Oggi(ore 8:00) consegno all'agente il DB di lavoro.
Io oggi, alle ore 10:00, lavoro sulla mia COPIA del BE, quindi i dati di modifica risalgono ad ogig ore 10.
 
L'agente ci lavora alle 14:00 del pomeriggio, poi domani rientra e diamo il via al FileSync... questo mi sostituisce il BE(dell'agente) in quanto più recente...? (Ovviamente non contiene le mie modifiche)...
 
Sicuramente questo SW deve essere più intelligente di me... che devo aver frainteso.
 
@Alex


la mia proposta del programma di sinc si basa su questa affermazione
 
"In ufficio non lavora nessuno."
 
altrimenti, casca il palco e il software non va bene
 
BFS
 
 
 

 BFS
 
Cercavo di capire proprio tecnicamente se questo SYNC è "intelligente" o meno... perchè con ACCESS usare la REPLICA, dal 2007 è impossibile... ed anche prima era da evitare..., quindi se fosse stato una cosa tecnicamente più evoluta poteva essere una cosa da considerare.
 
SQLServer ha il serivzio di gestione REPLICA, che funziona molto bene RMO, ma non è banale e non è FREE... oltretutto in casi di gestione da portatile è indiscutibile la comodità di Access...
 
Peccato.
 
@Alex
 


In questo caso, si porta dietro il FILE... ci lavora e quando torna lo COPIA INCOLLA... senza alcun SW esterno, tanto sa che lui è l'unico ad averci lavorato..., quindi sicuramente è l'ultimo.
 
Sbaglio qualche cosa..?
 
@Alex


se si tratta di un file solo, sicuramente basta fare un copia incolla.
 
ma siccome capita ed è capitato con un cliente che è riuscito a 
invertire il copia incolla sovrascrivendo il più recente con il meno 
recente avere una semplice icona su cui fare doppio click che faccia da 
solo toglie un pensiero. Infatti il programma permette di salvare il 
batch di sincro con una pratica icona sul desktop
 
il programma di sinc torna utile se oltre al db lavoro su altri file 
personali che vanno aggiornati una volta in sede
 
Altra soluzione può realizzare una maschera con due bei pulsanti "copia 
archivi da notebook a pc" e "copia archivi da pc a notebook" che faccia 
la copia in un vero o in un altro, magari backuppando i due file prima 
di ogni movimentazione.
 
 
BFS
 
 
 
 
 

Non sbagli Alex. L'ho appena chiamato per assicurarmi sul fatto che nessuno usa il pc fisso. Ma è anche vero che non è affatto pratico di pc e per di più sempre  di fretta. Potrebbe capitare qualche intoppo col copia e incolla. La soluzione dei due bottoni sarebbe più adatta. Ma non ho mai smanettato con questo tipo di routine (backup, copia etc) 
Una volta provai una routine di backup... e non funzionava. 
La pappa pronta in fondo ... è solo una chimera :-)


Quasi sempre, sì!
Ma anche se dovessi fare 10 query d'aggiornamento,
una volta testate singolarmente farle partire a
mitragliatrice è solo una goduria.
 
Prima di lanciare l'update la procedura dovrebbe
eseguire un Compact con codice personalizzato
tale da salvare copia del file compattato con
denominazione contenente data e ora dell'operazione.
 
Bruno