Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Stranezza ADO / ESP0DAMA

Questo è il comando corrispondente alla query (vista)
SubSectionsStrictExtended presente nel database ATECOFIN2004.mdb pubblicato
da Alessandro Riolo nel post di stamane e scaricabile da qui
http://www.sen.it/stoa/articles.asp?id=22
SELECT SubsectionStrict.Code, SubsectionStrict.Section,
SubsectionStrict.Code AS SubsectionStrict, "" AS Division, "" AS [Group], ""
AS Class, "" AS Category, SubsectionStrict.Description_IT,
SubsectionStrict.Description_DE FROM [Section] INNER JOIN SubsectionStrict
ON Section.Code = SubsectionStrict.Section;
Usando ESP0DAMA, ovvero aprendo il database e inserendo quel comando nella
zona Comando SQL, con  DAO funziona, mentre in ADO va in errore, come vanno
in errore i comandi di tutte le altre queries comprese nel database.
MsAcces (2000) apre regolarmente la query, e anche VisData (2000) la esegue
tranquillamente, anche come comando SQL.
Ho modificato ESP0DAMA per esporre ed eseguire anche le queries, ma non mi
riesce (in ADO) di eseguirle come semplici comandi (non come oggetti query).
E' evidente che il problema è in ESP0DAMA, ma davvero non capisco, visto che
in DAO funziona senza problemi...
Grazie per ogni indicazione.

 
Ho provato il seguente codice (al di fuori di ESPODAMA):
Dim rs As ADODB.Recordset
Set rs = New ADODB.Recordset
rs.Open "SELECT SubsectionStrict.Code, 
SubsectionStrict.Section,SubsectionStrict.Code AS SubsectionStrict, '' 
AS Division, '' AS [Group], '' AS Class, ''  AS Category, 
SubsectionStrict.Description_IT,SubsectionStrict.Description_DE FROM 
[Section] INNER JOIN SubsectionStrict ON Section.Code = 
SubsectionStrict.Section", _
"Provider=Microsoft.Jet.OLEDB.4.0;Data 
Source=D:\zip\ATECO2002.mdb;Persist Security Info=False", adOpenStatic, 
adLockReadOnly
rs.Close
Set rs = Nothing
Va in errore!
Secondo me il problema dipende dal fatto che i campi Code hanno 
dimensione diversa ed evidentemente ad ADO cio' non piace. Forse nella 
versione 2.8 hanno sistemato ...
ciao
	maxx
-- 
NOSPAM: Rimuovere i trattini dallo username!
Cut hyphens from my username!

 Va in errore!
Grazie. Stavo per perdere tempo a fare la stessa prova, giusto per escludere
(o confermare) ESP0DAMA.

Visto che si parla di esp0dama, vorrei porti una domanda.
Perchè se apro atecofin2004 mi dice, riguardo al numero di tabelle presenti
nel db, qualcosa come (9/15)
Non riesce a vedere le altre tabelle o cosa?
bye
-- 
Esistono 10 tipi di persone: chi conosce il binario e chi no.
www.nicolaottomano.it

 Non riesce a vedere le altre tabelle o cosa?
Tabelle di sistema?
-- 
Esteban
www.seber.it

> Tabelle di sistema?
tabelle del db.


 tabelle del db.
Esteban ti faceva notare che le 6 mancanti erano le tabelle di systema di
access, per vederle prova in a ciclare il tabledef, troverai tabelle che si
chiamano sys_.... !
-- 
<Gigio2K>
--- 
http://www.g2kweb.it/gigio2k
 ---
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/

ok tnx!


 Non riesce a vedere le altre tabelle o cosa?
Non espone le tabelle di sistema (puoi cercare nel codice qualcosa del tipo
".Attributes And dbSystemObject") non tanto perchè non sia possibile, ma
perchè la gestione (elenco campi, apri, elimina, rinomina, etc.) ne
risulterebbe poi molto difficoltosa, ma, soprattutto, molto rischiosa ai
fini dell'integrità del database e dei dati.
Quel (esempio) 9/15 indica che sono elencate 9 tabelle su 15 totali. Quindi
6 sono di sistema.

 
Ho scritto una stupidata perche' i campi uniti dalla JOIN sono dello 
stesso tipo e dimensione.
E' veramente strano. :-(


 
Sto sparando, ma in access non esiste qualcosa di simile alle collation 
dei campi di tipo testo di sqlserver?
section e code hanno 2 collation diverse e la join non funziona.
ciao


 section e code hanno 2 collation diverse e la join non funziona.
Non ti seguo. Cosa sono le collation? Perchè in DAO va?

Il 25/01/2004 11.08, Lupo scrisse:

Ripeto che potrebbe essere un'ipotesi completamente campata in aria.
In sql server i campi di tipo "testo" hanno anche una proprieta' che si 
chiama collation e che indica semplificando il set di caratteri 
utilizzato in quel campo. Ad esempio potresti dover inserire dei dati in 
giapponese ed allora specifichi la collation corrispondente (il set 
unicode corrispondente).
Quando sqlserver deve fare dei confronti tra campi testo si arrabbia se 
i campi hanno collation diverse, perche' ha poco senso confrontare il 
contenuto testuale di una campo in giapponese con uno contenente dati in 
arabo. Uno dei casi in cui avviene questo errore e' quando si fanno join 
tra 2 campi aventi collation diverse.
Non so se nelle ultime versioni di access hanno introdotto questo 
concetto, non posseggo access. Se hai la possibilita' di verificare ...
Perche' funziona in DAO? Forse DAO non si pone il problema della 
collation visto che non e' fatto per sqlserver.


 collation visto che non e' fatto per sqlserver.
Ma dici (se quello fosse il problema) che ADO se ne preoccuperebbe? Mmmmm

 
Ho guardato con Visdata le proprieta' dei campi:
per section.code e SubsectionStrict.section il collatingOrder e' lo 
stesso, 1033, mentre l'UnicodeCompression e' diversa nei 2 campi. Non mi 
intendo molto di questi dettagli e quindi mi fermo qui.


Non ci ho capito un fico secco leggendo tutto il post,
a parte il fatto che una query non funziona con ado.
Ora premnesso che non sň bene dove sia reperibile
quel database, ne ho mai scaricato e provato espodama,
direi che la cosa piů logica che mi viene in mente č che
state utilizzando una parola chiave che access in ado
considera come comando ...
L'ho sparata ... ma visto che ne con espodama ne con
una query diretta funziona ,... provate per lo meno
ad eseguire la stessa query dentro alla select di access
e vedete cosa succede. Se la query funziona c'č
qualche cazzata scritta tra ado, vb e compagni, se non
funziona č avvalorata la mia tesi.
Ciao
Andrea

 considera come comando ...
Se cosě fosse basterebbe usare le quadre, come non č possibile usare un
campo NOTE (alias di MEMO) ma [NOTE].
Ciao
--
Math Parser : 
http://www.neodatatype.net
Sito Comune : 
http://www.it-lang-vb.net

 ... leggendo tutto il post,
sicuro? ;-)

Il 25/01/2004 14.25, Andrea Moro scrisse:

La query non funziona con ado, a prescindere da espodama.
Il db lo trovi nel post di alessandro riolo del 23 [Download] ATECO 2002.
Con access, che non ho, immagino che funzioni visto che dalla struttura 
del db sembra fatto in access.
Cosi' funziona:
SELECT t.Code, t.[Section],
t.[Code] AS SubsectionStrict, "" AS Division, "" AS [Group], ""
AS Class, "" AS Category, t.Description_IT,
t.Description_DE FROM [Section] as s INNER JOIN SubsectionStrict as t
ON s.Code = t.[Section]
Section deve essere una parola riservata di ado ...


 
Cosi' funziona:
SELECT SubsectionStrict.Code, SubsectionStrict.[Section],
SubsectionStrict.Code AS SubsectionStrict, "" AS Division, "" AS [Group], ""
AS Class, "" AS Category, SubsectionStrict.Description_IT,
SubsectionStrict.Description_DE FROM [Section]  as s INNER JOIN 
SubsectionStrict
ON s.Code = SubsectionStrict.[Section]
quindi basta sostituire Section con [Section] e mettere un alias alla 
tabella section.
Serve un parser ;-)


Il 25/01/2004 15.18, emmexx scrisse:
E per concludere:
Questa funziona:
select * from [Section]
questa no:
select * from Section


 select * from Section
Ebbravo!
Ecco una prima (parziale) conferma (ovviamente nei BOL SECTION non viene
menzionata come reserved)
http://support.microsoft.com/default.aspx?scid=kb;en-us;287417
Io smetto di cercare, smetto anche di dire che dovevano (!) decidere le
reserved words anteponendo a tutte xyz o anche ms. Dilettanti.

 Serve un parser ;-)
Pronto (VBP0PSQL) (vabbè, ho cambiato "" in ''):
(1,1) Select SubsectionStrict.Code
(2,1) As
(1,2) Select SubsectionStrict.[Section]
(2,2) As
(1,3) Select SubsectionStrict.Code
(2,3) As SubsectionStrict
(1,4) Select ''
(2,4) As Division
(1,5) Select ''
(2,5) As [Group]
(1,6) Select ''
(2,6) As Class
(1,7) Select ''
(2,7) As Category
(1,8) Select SubsectionStrict.Description_IT
(2,8) As
(1,9) Select SubsectionStrict.Description_DE
(2,9) As
(1,1) From [Section]
(2,1) As s INNER JOIN SubsectionStrict ON s.Code =
SubsectionStrict.[Section]

Quindi la mia teoria č confermata ... anche perchč ora
che ci penso Section č un oggetto del report di access.
Quindi era quasi logico che non funzionasse.
Tolto questo, direi che c'č proprio un errore di fondo
su come impostare una base dati.
Premesso che non sono nemmeno io un dio, ma se
si anteponesse per ogni tabella una prefisso del tipo
tabella section = prefisso sec_
tutto sarebbe piů pulito per access e ado che funzionano
alla grande, per chi legge codice sql come esterno che
con poco intuisce quale campo č che appartiene ad
una data tabella senza parentesi quadre del caso o
senza parser di emmex :)))
Poi fate vobix, sono 8 anni che faccio db cosě e fatta
eccezione del primo nel quali rimasi scottato con il
campo note ... che non capivo perchč diavolo non
funzionava ... ho smesso di preoccuparmi usando questa
semplice tecnica ...
Ciň non toglie che comunque il nome tabella non dovrebbe
assumere nomi particolari come quello poc'anzi visto.
Ciao
Andrea

 tabella section = prefisso sec_
E perchè non l'hanno fatto loro, una volta per tutte, invece che tutti noi,
ogni volta?
Per tabelle, campi, variabili di programma e tutto in genere? Eh?!
Che gli costava dire "signori, quel che inizia con pippo_ è roba nostra, top
secret, da non usare, da dimenticare nei secoli"? Eh, che gli costava? <eg>

 senza parser di emmex :)))
Il tuo parser binoculare si e' perso una x: emmexx, prego!
:-)
	maxx
Il problema di fondo pero' e' la solita incompatibilita' tra prodotti MS.
Se a chi  ha creato le tabelle fosse apparsa una bella segnalazione (di 
access o di DAO o di vattelapesca) "nome tabella non consentito o 
ambiguo" non staremmo qui a perdere tempo inutilmente.
Invece access funziona, dao funziona, ado funziona con le quadre, ecc.
A volte sembra quasi di chiedere cose fuori dal mondo.
:-(


 secret, da non usare, da dimenticare nei secoli"? Eh, che gli costava? <eg>
Piu' che un prefisso, come dicevo ad Andrea, un controllo sulle parole 
chiave. Le parole chiave sono off-limit e basta.


 chiave. Le parole chiave sono off-limit e basta.
Appunto. Tutto ciò che inizia con pippo_ è parola chiave, in qualsiasi
strumento, applicativo, linguaggio, mondo ed universo. Lo si scrive una
volta sola e, addirittura, non lo si testa nemmeno: chi usa "pippo_section"
è un piccio. Chi usa "section" è un essere normale.

 
Pero' immagina una cosa cosi':
MS_SELECT tabella1.campo1, ... MS_FROM tabella1 MS_INNER MS_JOIN 
tabella2 MS_ON tabella2 MS_WHERE ...
MS_GROUP MS_BY
MS_ORDER MS_BY
;-)


A volte sembra quasi di chiedere cose fuori dal mondo.
E' fuori dal mondo credere che access sia un database.
-- 
ciao, hal

 ORDER BY SeMiChiamiMsEcceteraSeiUnPiccio_...
Mi son spiegato? Ms_E'CosìFacile!

 SubSectionsStrictExtended presente nel database ATECOFIN2004.mdb
cut e zac
mi son tenuto ai margini....però ora mi stimola intervenire (quando scappa
....scappa!)
Hal è intervenuto .....ha detto la sua....è ha ragione
Lupo ha ragione
Emmex ha ragione
tutti hanno ragione ....sta a vedè che ho torto io?
:-)
alcuni Punti
 a) DAO non esiste più.....se lo usi....cerchi alcune cose che solo con
quello puoi fare ...ossia: un ottimo interfacciamento con access e PUNTO!
Non sei un bischero ad usare DAO....anzi sei un furbo che vuol spremere il
massimo da access...però finisce li!
Non mi puoi mischiare ado e dao...ne IMHO...far paragoni....
Paragoneresti una monovolume ed un veicolo commerciale???
Con la monovolume in teoria porti anche i sacchi di cemento...con il camion
in teoria ci carichi la famiglia e la porti al mare!
il paragone sembra grullo ma non lo è
DAO spreme in abbinamento ad access....ADO è fatto per fare un porting
veloce verso DB "altri"
DAO non ha senso al di fuori di access...ADO (a meno che non si pensi alla
futura evoluzione dell'applicazione) non ha senso con Access monoutente!
b) Lupo ce l'ha con ADO....vecchia storia....con i suoi alti e bassi ma
sostanzialmente lo odia! che ce vo fà.....io odio Delphi...senza motivo...a
paelle...c'ho provato un sacco di volte...non mi va giù
c) Access ha tanti pregi....
c-bis) ...tanti pregi per un professionista!
per un commercialista.....tiri giù un db in poco tempo...ti fai le tue
stampe...etc etc...è facile da usare...c'hai un solo file a giro per il
pc...è "carino" da usare.
Per un programmatore è un altro discorso...e ha ragione Hal "definiamo
access un DB?"
d)l'mdb che contiene sto ateco
....HA un senso!
c'ho dato un occhiata...funziona benissimo all'interno di access...usa tutti
le "singolarità" di access
sicuramente un utente evoluto l'ha preso e riempito. Sicuramente (spero!)
non era un programmatore!
e) Lupo invecchia :-)
vorrebbe fare sempre meno fatica!
Ha ragione...ma purtroppo per sto ateco è impossibile!
o meglio....se hai uno "schiavo" in ufficio (dicesi schiavo ragazzino in
fase di stage presso di te)...falli costruire un mdb "fatto bene" a partire
da sto ateco...
...almeno lo schiavo impara qualcosa ....
f)
le parole chiave
....se sei un programmatore standard di access...manco sai che sono le
parole chiave!
MA
per la diffusione di access e per alcune sue doti (installare msde per una
gestione di una officina non serve!..per una contabilità monoutente
neppure!)
il suo utilizzo si è "espanso"
...ma allora dovresti sapere tu cosa fare!
in vb lo faresti:
dim set as string ?
no perchè l'ide si incazza
l'sql come fa ad incazzarsi?...a meno che tu non usi validatori di
espressioni...si incazza solo quando esegui lo "script" sql...
in sostanza
stavolta mi sento di assolvere m$ (caz sto diventando buono)
....
di assolvere il costruttore dell'mdb che di sicuro non era un esperto di sql
ne un programmatore
....
di assolvere Lupo (parzialmente) che nella sua "smania" contro m$ si era
dimenticato di controllare le parole chiave (un sintomo era che nel mio
access racchiudeva il nome della tabella tra [] come detto nel tuo link)
...
è un mondo difficile ci voglion occhi dappertutto!
eh eh eh!
:-)
-- 
Il Wodkino Nazionale è a : 
www.martek.it
Pagina Vb/Bestiario/Lamer Experience :
http://www.martek.it/go.asp?portamia=2
 Quotefix e altro:
http://www.martek.it/go.asp?portamia=4
Usr: ICLVB Pw: amici

 ...
Questa e' la query memorizzata nel database:
SELECT SubsectionStrict.Code, SubsectionStrict.Section, 
SubsectionStrict.Code AS SubsectionStrict, "" AS Division, "" AS 
[Group], "" AS Class, "" AS Category, SubsectionStrict.Description_IT, 
SubsectionStrict.Description_DE FROM [Section] INNER JOIN 
SubsectionStrict ON Section.Code = SubsectionStrict.Section
Questa e' quella funzionante:
SELECT SubsectionStrict.Code, SubsectionStrict.[Section],
SubsectionStrict.Code AS SubsectionStrict, "" AS Division, "" AS [Group], ""
AS Class, "" AS Category, SubsectionStrict.Description_IT,
SubsectionStrict.Description_DE FROM [Section]  INNER JOIN SubsectionStrict
ON [Section].Code = SubsectionStrict.[Section]
Perche' Access si degni di fare la sostituzione automatica delle parole 
chiave con [...] ma non di memorizzare la query cosi' trasformata, non 
lo so.
So solo che io non uso access e se accedo ai dati contenuti in access 
Section non esiste. Cosa mi importa se all'interno di un programma 
(access) viene usato il termine section per una funzionalita' che al di 
fuori di access non e' disponibile? Quelli di MS si sono forse 
dimenticati di tutte le librerie di accesso ai dati che hanno scritto e 
distribuiscono con tanta frequenza?
ciao


 č un mondo difficile ci voglion occhi dappertutto!
Certo, ma quando l'hai visto non puoi far finta di niente.
No, non lo dico, ma non posso far finta di niente.
Nč trovo piacevolissimo farmi rovistare nel culo.


cut
beh non č un prodotto per quel target di utenti...brutto da dire ma č cosě
e poi...sopratutto:
in access funziona!!!
ergo
non č proibita in access!
Occhio al punto!
...a Lupo non funziona con ADO!
all'interno di Access e con DAO dice( e almeno per access confermo) tutto
funziona!
Loro ti dicono:
"nel mio mondo chiuso e parziale quanto vuoi...tutto va!...oltre vai a
rischio e perizia tua!...anche se usi prodotti miei!"
Tutti sappiamo la gestione (ad esempio)  arzilla delle date di access e dei
(oramai consueti) "aggiustamenti" da fare con ADO"....
ora sappiamo delle parole chiave (chi non lo sapeva ora lo sa)
il fatto č che una comunitŕ di programmatori usa access per scopi forse
troppo "alti" rispetto a quelli che microzozz pensava...il fatto di dare
msde...č un cercare una toppa da parte loro (IMHO)...un chiudere la stalla
quando i buoi son scappati!
divagazione per il freddo:
un altro esempio č che se abbino un IIS ad asp mi trovo per forza un access
come scelta obbligata di db....i prezzi di un sqlserver(praticati da un
provider) son troppo alti per siti che non siano ecommerce...(mysql lasciamo
stare eh!)si spera che con aruba si muova qualcosa...sperem!
Ciao! :-)

 chiudere la stalla quando i buoi son scappati!
Non mi pare che qui si stia parlando di Access o di MSDE (e Access non è
meno database per una parola chiave che può aver creato un problema, prova
il campo FILE in SQL Server, prova, su...), qui si sta parlando di parole
chiave e della loro gestione, siano esse in VB, in SQL, DAO o ADO, in Access
o SQL Server. E anche per quel che ancora non è stato inventato.
Una buona gestione garantirebbe tranquillità per tutti.
Tu dici che la gestione te la fai te (resto basito, ma rispetto la tua
scelta), io dico che dovevano farla loro.
Dico/ribadisco anche che sono degli sfaticati.

 Nč trovo piacevolissimo farmi rovistare nel culo.
Sei sempre un sacco tragico!
....microzozz fa schifo anche a me...ma insomma.... tu sei "contro a
prescindere!"
e poi....
chissa che puzzo c'č nel tuo culo!!!
io non ci metterei le mani neanche per 1 milione di euro!
:-)
e poi lo sai...alternative ce ne sono.....
ma come hai detto una volta ...alla tua etŕ non hai voglia di ripartire!
e allora non c'č strada.....incazzati quanto vuoi....ma ti tocca stare alla
bontŕ di zio bill
:-D
.....
ah una cosa Lupo....
non so se vuoi andare in pensione presto.....
se si sbrigati!!!!!
Altrimenti fra qualche anno saremo tutti ad ascoltare le tue imprecazioni su
ADO.net
....io giŕ me le pregusto!!!
LOL e pure ROTFL
Ciao!....e ddai che al prossimo meeting...doppia boccia per Lupo!
:-)
-- 
Il Wodkino Nazionale č a : 
www.martek.it


con un motoredb diverso
L'inghippo sta nel fatto che la gente, confusa e mal indirizzata dalla
falsa propaganda commerciale di Microsoft, continui ad usare gli mdb
come se fossero database client-server, ma tanto varrebbe continuare
ad usare i dbf.
-- 
ciao, hal

 ad usare i dbf.
sottoscrivo al 101%
