OLE DB e recordset Aggiornabili da maschere

[OneEDP]

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

[Oscar Manfredini]

"OneEDP" <

Post by OneEDP
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?

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

[OneEDP]

Post by Oscar Manfredini
"OneEDP" <

Post by OneEDP
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?

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

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

[Oscar Manfredini]

"OneEDP" <

Post by OneEDP
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.

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

[Alessandro Baraldi]

On 23 Apr, 09:34, "OneEDP"

Post by OneEDP
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

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

[OneEDP]

"Alessandro Baraldi" <***@libero.it> ha scritto nel messaggio news:8ec4132c-28df-4c52-b330-***@s50g2000hsb.googlegroups.com...
On 23 Apr, 09:34, "OneEDP"

Post by OneEDP
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

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

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

[Alessandro Baraldi]

On 28 Apr, 10:18, "OneEDP"

Post by Alessandro Baraldi
On 23 Apr, 09:34, "OneEDP"

Post by OneEDP
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

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
Ti incollo questa uno stralcio di quetahttp://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

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

[OneEDP]

"Alessandro Baraldi" <***@libero.it> ha scritto nel messaggio news:ae655dfe-50e9-4357-86c6-***@x41g2000hsb.googlegroups.com...
On 28 Apr, 10:18, "OneEDP"

Post by Alessandro Baraldi
On 23 Apr, 09:34, "OneEDP"

Post by OneEDP
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

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
Ti incollo questa uno stralcio di
quetahttp://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
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

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

[Alessandro Baraldi]

On 28 Apr, 12:42, "OneEDP"

Post by Alessandro Baraldi
On 28 Apr, 10:18, "OneEDP"

Post by Alessandro Baraldi
On 23 Apr, 09:34, "OneEDP"

Post by OneEDP
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

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
Ti incollo questa uno stralcio di
quetahttp://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
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

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.

Guarda che c'è qualche cosa che non torna...!
Una Form basata direttamente su Tabella(non query per essere sicuro
che non
contenga inefficienze) collegata via ODBC non può avere rallentamenti
rispetto ad OLE... e deve essere velocissima... se così non fosse
fossi in te ricercherei li il problema...!

Tieni presente sempre che sarebbe sempre bene tenere aperta una
connessione ad una Tabella vuota da una maschera Hidden magari...
questo ti consente di evitare all'apertura delle Form di generare una
nuova istanza di Connessione, il che velocizza molto.

Ci sono poi molte cose da verificare... se hai delle ComboBox con
origineRiga delle SELECT non ottimizzate o altre cose che possono
minare la velocità....

Post by Alessandro Baraldi
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.

Nonho capito la domanda...!

Post by Alessandro Baraldi
Grazie
Daniele-

@Alex

[OneEDP]

"Alessandro Baraldi" <***@libero.it> ha scritto nel messaggio news:9715aa7b-e57a-40cf-b9a3-***@a70g2000hsh.googlegroups.com...
On 28 Apr, 12:42, "OneEDP"

Post by Alessandro Baraldi
On 28 Apr, 10:18, "OneEDP"

Post by Alessandro Baraldi
On 23 Apr, 09:34, "OneEDP"

Post by OneEDP
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

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
Ti incollo questa uno stralcio di
quetahttp://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
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

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.

Guarda che c'è qualche cosa che non torna...!
Una Form basata direttamente su Tabella(non query per essere sicuro
che non
contenga inefficienze) collegata via ODBC non può avere rallentamenti
rispetto ad OLE... e deve essere velocissima... se così non fosse
fossi in te ricercherei li il problema...!

Tieni presente sempre che sarebbe sempre bene tenere aperta una
connessione ad una Tabella vuota da una maschera Hidden magari...
questo ti consente di evitare all'apertura delle Form di generare una
nuova istanza di Connessione, il che velocizza molto.

Ci sono poi molte cose da verificare... se hai delle ComboBox con
origineRiga delle SELECT non ottimizzate o altre cose che possono
minare la velocità....

Post by Alessandro Baraldi
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.

Nonho capito la domanda...!

Post by Alessandro Baraldi
Grazie
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

[Oscar Manfredini]

"OneEDP" <


(cut)

Post by OneEDP
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.

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

[OneEDP]

Post by Oscar Manfredini
"OneEDP" <
(cut)

Post by OneEDP
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.

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

Il throughput di rete triplica in ingresso e quadruplica in uscita anche con
interrogazioni limitate su recordset con chiave univoco.
L'impressione che ho è come se avessi specificato adCmdTableDirect, per cui
ottengo un select * from... piuttosto che i campi specificati.
Si ha il solo vantaggio di ottenere recordset aggiornabili (su tabelle
univoche a lato destro join). Ma è dispendioso.
Frustrante, ma sono fiducioso.
Daniele

[Oscar Manfredini]

"OneEDP" <

Post by OneEDP
Il throughput di rete triplica in ingresso e quadruplica in uscita anche con
interrogazioni limitate su recordset con chiave univoco.
L'impressione che ho è come se avessi specificato adCmdTableDirect, per cui
ottengo un select * from... piuttosto che i campi specificati.
Si ha il solo vantaggio di ottenere recordset aggiornabili (su tabelle
univoche a lato destro join). Ma è dispendioso.
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

[Oscar Manfredini]

"Oscar Manfredini"

Post by OneEDP
Il throughput di rete triplica in ingresso e quadruplica in uscita anche

con

Post by OneEDP
interrogazioni limitate su recordset con chiave univoco.
L'impressione che ho è come se avessi specificato adCmdTableDirect, per

cui

Post by OneEDP
ottengo un select * from... piuttosto che i campi specificati.
Si ha il solo vantaggio di ottenere recordset aggiornabili (su tabelle
univoche a lato destro join). Ma è dispendioso.
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

[OneEDP]

Post by Oscar Manfredini
"Oscar Manfredini"

Post by OneEDP
Il throughput di rete triplica in ingresso e quadruplica in uscita anche

con

Post by OneEDP
interrogazioni limitate su recordset con chiave univoco.
L'impressione che ho è come se avessi specificato adCmdTableDirect, per

cui

Post by OneEDP
ottengo un select * from... piuttosto che i campi specificati.
Si ha il solo vantaggio di ottenere recordset aggiornabili (su tabelle
univoche a lato destro join). Ma è dispendioso.
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

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

[Oscar Manfredini]

"OneEDP"

Post by OneEDP
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).

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

[OneEDP]

Post by Oscar Manfredini
"OneEDP"

Post by OneEDP
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

Post by OneEDP
da server ed è frustrante (le impostazioni ODBC sono state provate in

tutte

Post by OneEDP
le salse).
Una query basata sulla tabella collegata impegna il server decisamente

molto

Post by OneEDP
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

Grazie comunque

[Alessandro Baraldi]

On 28 Apr, 19:25, "OneEDP"

Post by OneEDP

Post by Oscar Manfredini
"Oscar Manfredini"

Post by OneEDP
Il throughput di rete triplica in ingresso e quadruplica in uscita anche

con

Post by OneEDP
interrogazioni limitate su recordset con chiave univoco.
L'impressione che ho è come se avessi specificato adCmdTableDirect, per

cui

Post by OneEDP
ottengo un select * from... piuttosto che i campi specificati.
Si ha il solo vantaggio di ottenere recordset aggiornabili (su tabelle
univoche a lato destro join). Ma è dispendioso.
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

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-

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

[OneEDP]

"Alessandro Baraldi" <***@libero.it> ha scritto nel messaggio news:abd06170-633b-4e47-b677-***@k37g2000hsf.googlegroups.com...
On 28 Apr, 19:25, "OneEDP"

Post by OneEDP

Post by Oscar Manfredini
"Oscar Manfredini"

Post by OneEDP
Il throughput di rete triplica in ingresso e quadruplica in uscita anche

con

Post by OneEDP
interrogazioni limitate su recordset con chiave univoco.
L'impressione che ho è come se avessi specificato adCmdTableDirect, per

cui

Post by OneEDP
ottengo un select * from... piuttosto che i campi specificati.
Si ha il solo vantaggio di ottenere recordset aggiornabili (su tabelle
univoche a lato destro join). Ma è dispendioso.
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

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-

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

[Alessandro Baraldi]

[cut]

Post by OneEDP
Forse la ragione sta in questo. Ma credo più in una inefficienza del driver
odbc.

E' la prima ipotesi che aveva fatto anche Oscar e sulla quale mi trovo
concorde.

Post by OneEDP
 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?

Non ho la più pallida idea non avendolo mai fatto... ma in linea
teorica Win98
dispone già delle dll(32 bit) quindi non dovrebbe avere
problemi(dovrebbe)...

Post by OneEDP
La CursorLocation può essere impostata anche adUseServer?

Se usata lato Client no... mi risulta sia impostabile solo
adUseClient... ma
non sono espertissimo con ADO...

Post by OneEDP
Ciao
Daniele

Ciao
@Alex