Newsgroup: it.comp.appl.access
Titolo: OLE DB e recordset Aggiornabili da maschere

Sul sito di Alessandro ho trovato la possibilità di rendere un recordset 
aggiornabile basato sul provider OLE DB SQL di MS.
Ho urgernza di rendere all'interno di Access 2000 aggiornabile recordset 
(consumer ADO 2.5 o superiore) basato sul provider IBMDA400 su dati 
residenti su As/400.
Via ODBC è stato possibile, ma le prestazioni potete immaginarle.
Esite una soluzione?
Grazie
Daniele 

"OneEDP" <


Via ODBC utilizzo solo MS SQL Server e le prestazioni sono ottime.
Sono tanto infami con IBM DB/2?
Cosa fa l'applicazione?
Ciao: Oscar

On 23 Apr, 09:34, "OneEDP"

Dubito che il problema sia ODBC quanto magari al fatto che stai
facendo eseguire il codice SQL Client_Side avendo inserito funzioni
non riconoscosciute dal Motore del DB... come aggregazioni sui domini
o altre che obbligano a farti rielaborare in locale i dati....
La differenza tra i 2 provider in termini prestazionali è decisamente
trascurabile...
@Alex

 ha scritto nel messaggio 
news:4812140b$0$41661$4faf...@reader4.news.tin.it...

Se collego le tabelle  in MDB ho registrato un surplus nel traffico di rete 
ed un impegno del server eccessivo... perché le tabelle vengono poi gestite 
dal Jet all'interno delle maschere e per questo sono editabili... diciamo 
che non si può parlare veramente di client-server in questo caso.
Daniele 

 ha scritto nel messaggio 
news:8ec4132c-28df-4c52...@s50g2000hsb.googlegroups.com...



@Alex
Ti incollo questa uno stralcio di queta 
http://support.microsoft.com/kb/227053/en
Data Source Based on Other Data Sources
If the source of data for the form is provided by any other source, such as 
the Microsoft Jet database engine, you cannot create an ADO recordset that 
can be edited with a form, even if you can edit the recordset directly with 
ADO. The only solution in this case is to use Data Access Objects (DAO) to 
create the recordset, and then to assign the recordset to the form's 
Recordset property. DAO is highly optimized for the Microsoft Jet database 
engine, and can access a number of ISAM or ODBC data sources that are 
accessible by the Jet database engine.
If you are using an ISAM or ODBC data source, link the table to a Microsoft 
Jet database (.MDB) and use DAO to open a recordset based on the linked 
table. As long as the recordset can be edited directly via DAO, a form based 
on the recordset can be edited as well. To create a DAO recordset that can 
be edited in a Microsoft Access form, follow these steps.
ESATTAMENTE ciò che voglio evitare.
Hai da suggerirmbi qualche workaround meno dispendioso? Recordset 
disconnessi? Query Asincrone... (penso che non c'entrano nulla, ma a volte i 
data provider sono anachici)
Ciao e grazie
Daniele

 che non si può parlare veramente di client-server in questo caso.
Evidentemente è un problema del Driver ODBC che stai utilizzando.
Con altri Server di DataBase le cose NON stanno così: in locale arriva solo
la pagina di dati visualizzata sullo schermo.
Se apri una linked table ODBC popolata con molti records, i tempi di
risposta e la gestione del video risultano pesanti?
In tal caso non c'è nulla da fare.
Ciao; Oscar

 Daniele
Il link da usare per ADO è questo:
http://support.microsoft.com/kb/281998
Per i Recordset disconnessi direi che nè ADO(in realtà i potrebbe con
Recordset in memoria fare un UpdateBatch ma non sarebbe efficiente in
quanto i tempi di apertura delle connessioni si allungherebbero e
bisognerebbe sempre tenere aperta una connessione) nè DAO lo
consentono, solo da NET è possibile...!
Per gli altri problemi concordo con Oscar in merito al Driver che
usi... in quanto se il codice SQL è ben strutturato viene sempre
eseguito ServerSide... addirittura anche la Proprietà FILTER delle
Form viene rieseguita ServerSide ottimizzando l'estrazione dati....
Ricorda oltretutto che Access, a meno di usare ADP, usa sempre DAO...
pertanto non credo sia il massimo passare per un provider ADO che
viene riconvertito da JET-ENGINE in DAO...
@Alex


http://support.microsoft.com/kb/281998

A questo punto devo ripiegare su ODBC (ma ho certificato che il throughput 
di rete è ben maggiore con IBM) o utilizzare l'OLE DB IBMDA400 con 
aggiornamenti non a livello di record ma   impartendo continuamente e 
frequentemente satement SQL/400 del tipo SELECT.... UPDATE.... e... resync e 
dando all'utente una maschera su snapshot scaricati localmente... ma la vedo 
ardua.
A proposito di JET-ENGINE -> DAO, tu cosa implemeteresti il front-end da 
fonte dati in As400 avendo client win98/me/xp?
Aspetto vostri suggerimenti.
Grazie
Daniele
 

 Daniele-
@Alex

 Aspetto vostri suggerimenti.
Ma hai fatto la prova che ti dicevo?
Se le performances di apertura, filtro, gestione di una semplice linked
tabel ODBC sono buone o no?
Ciao: Oscar

 Frustrante, ma sono fiducioso.
Allora, un Driver ODBC scritto secondo specifiche non funziona in quel modo.
Se tu avessi modo di connettere un'applicazione a MS SQL Server,
riscontreresti comportamenti di questo genere:
http://www.alessandrobaraldi.it/DettaglioFaq.asp?IdFAQ=281
Cito quella documentazione, perchè è in Italiano.
Può darsi pure che ci siano dettagli legati alla connettività al AS/400 che
complicano la questione.
Ma normalmente ODBC non si comporta come tu stai rilevando.
Ciao: Oscar

 Daniele-
@Alex
Dove sono i ">"?!
Ho appena risposto a Oscar: Il throughput di rete triplica in ingresso e 
quadruplica in uscita anche con interrogazioni limitate su recordset con 
chiave univoco.
La prova che sto eseguendo è una semplicissima select tabella con record da 
350 car e chiave univoc composta da 17 car.
I risultati come tempi sono accettabili ma l'impegno di banda è gravoso e da 
remoto gli utenti mi spellerebbero vivo.
La domanda che ti ponevo è questa. Visto che il DB in AS/400 attraverso 
l'OLE DB deve "passare" per il consumer ADO 2.x  e poi per il JET ENGINE -> 
DAO per rendere editabili le form... che soluzione hai utilizzando Access 
2000 su client win98/me/xp per un front-end come si deve?
Grazie
Daniele

 > Frustrante, ma sono fiducioso.
Scusa se insisto (tu non fai quello che ti chiedo): se apri un tabella
collegata ODBC dall'interfaccia di Access, una tabella grossa, cosa succede?
Ciao: Oscar

 ha scritto nel messaggio 
news:48160517$0$18157$4faf...@reader3.news.tin.it...

Ottengo n record e scrollando page down un'altro gruppo di record viene 
inviato dal server.
Il traffico di rete registra dati in uscita pari la metà di quelli ricevuti 
da server ed è frustrante (le impostazioni ODBC sono state provate in tutte 
le salse).
Una query basata sulla tabella collegata impegna il server decisamente molto 
di più che con una query pass-through (ovviamente).
Non esitare se hai altri dubbi.
Daniele 

 di più che con una query pass-through (ovviamente).
Questo è il punto: se la query non contiene elementi estranei al Driver ODBC
viene sempre eseguita lato server.
Anche se basata su tabelle collegate.
Spiacente di non poterti essere utile: non ho esperienza con AS/400.
Ciao: Oscar

 ha scritto nel messaggio 
news:48160a34$0$18148$4faf...@reader3.news.tin.it...

Grazie comunque 

 Daniele-
Perchè ovviamente....?
La Query PT viene interpretata ServerSide esattamente come una normale
Query se questa non ha al suo interno elementi che la obbligano alla
rielaborazione Client_Side.... !
Verifica una cosa tipo questa:
Crea una Q_PT :
SELECT CampoPK FROM T1 WHERE CampoPK=1
Stessa Query su Linked Table....
L'impegno per il Server e per la rete deve essere lo stesso.
@Alex

>>>>
Purtroppo no nelle tabelle collegate la select viene trattata come select * 
from .... e poi nella elaborazione della where dal pc viengono inviati dati 
pari alla lunghezza del record e non solo quelli relativi alla chiave.
Ti incollo uno stralcio da articolo da infomedia CP.
Se si usa il provider OLE DB per ODBC, il cui nome (progID) è MSDASQL, si 
finisce per individuare un oggetto COM che invoca il runtime manager di ODBC 
per individuare il driver e poi accedere ai dati. Optando per il provider 
nativo, invece, l'accesso ai dati è immediato.
Ti riporto il link 
http://online.infomedia.it/riviste/cp/94/articolo16/
Forse la ragione sta in questo. Ma credo più in una inefficienza del driver 
odbc.
Comunque l'articolo 
http://support.microsoft.com/kb/281998
 cita:
 Microsoft Access 2002 e le versioni successive consentono di creare una 
maschera aggiornabile associata a un recordset ADO che utilizza altri 
provider OLEDB. È necessario che la maschera soddisfi una serie di requisiti 
generali affinché sia aggiornabile quando è associata a un recordset ADO. 
Tali requisiti generali sono i seguenti: 1. Il recordset ADO sottostante 
deve essere aggiornabile.
      2. Il recordset deve contenere uno o più campi indicizzati in modo 
univoco, ad esempio una chiave primaria di una tabella.
Gli altri requisiti di aggiornabilità sono diversi a seconda dei provider.
A questo punto sai dirmi se Access 2002 è installabile su Win 98/ME?
La CursorLocation può essere impostata anche adUseServer?
Ciao
Daniele

 Daniele
Ciao
@Alex