Newsgroup: it.comp.lang.delphi
Titolo: Non ne vengo fuori. Idee ?

Sono tre giorni che lotto con il prob lema di una Query che mi dà "Type 
mismatch". La query è la seguente:
SELECT * FROM "Africa.DBF"   UNION ALL SELECT * FROM "Italiani da 
trovare.DBF"
L'ambiente è, lo confesso, il BDE e i files sono dBase. Ma il vero problema 
è che se in questa stessa query sostituisco "Italiani da trovare.DBF" con 
"Francesi da trovare.dbf" o "Arabia.dbf", allora va bene!!!
SELECT * FROM "Africa.DBF"   UNION ALL SELECT * FROM "Arabia.DBF"     è OK!!
Tutti i dataset hanno identica struttura. Cosa può causare il problema ? Ho 
provato a controllare il contenuto, ma non vedo niente di particolare. Ho 
copiato i files, reindicizzato, etc. Non ne vengo fuori. Lo so che nessuno 
sa più niente di dBase, ma non mi pare un problema dBase. Qualcuna ha 
qualche idea che possa aiutarmi a trovare il bandolo ??
(Non rispondetemi picche perchè uso dBase. L'applicazione funziona da più di 
dieci anni e l'unica cosa che volevo fare è lavorare con l'unione di più 
dataset uguali e fisicamente separati, come se invece fossero uno unico..)

 dataset uguali e fisicamente separati, come se invece fossero uno unico..)
L'unica cosa che mi viene in mente, è che osservando i nomi dei files 
quello che non funziona ha degli spazi al suo interno.
Un'alternativa potrebbe essere eseguire le query separatamente, e 
popolare un CDS per poi lavorare con tutti i record in memoria.
PS:
Ho lavorato anche io per anni con i dbf, e ti confesso che non ne sento 
proprio la mancanza ;-)
-- 
Morde

Prova a controllare se hai qualche campo NULL.
Matteo

 ha scritto nel messaggio 
news:496aec51$1...@newsgate.x-privat.org...


 SELECT * FROM "Africa.DBF"   UNION ALL SELECT * FROM "Arabia.DBF" è OK!!
Ti da errore se accedi alla tabella senza la union (SELECT * FROM 
"Italiani da trovare.DBF") ?
ciao
Giacomo

 Tu con cosa lo hai sostituito?
Iterbase Firebird. Ma non e' il solo che possa sostituire i dbf, cerca 
su questo ng nei post passati, ci sono migliaia di messaggi a riguardo.
-- 
Morde

 questo tipo (monoutente e su una sola macchina)
Sostituire i dbf con altro non è una cosa immediata.
Se funziona, non vedo perchè fare cambiamenti.
Quando e se darà problemi, sarà meglio fare un refactoring della
applicazione e usare firebird emmbedded, ad esempio.
Tornando al tuo problema, fai una select solo sul dbf incriminato,
funziona o no?
E, prima di cio', il dbu te la apre?
ciao

 ha scritto nel messaggio 
news:9014f47f-f238-47f0...@w39g2000prb.googlegroups.com...


 ha scritto nel 
messaggio news:JcOal.156247$Ca.2...@twister2.libero.it...


 ha scritto nel messaggio 
news:496a8706$0$1113$4faf...@reader3.news.tin.it...


 Sembra di poter concludere che il contenuto non c'entra con il problema..
con la select estrai sempre colonne, quindi e' la struttura della 
tabella ad essere in gioco, mai il contenuto.
Ad ogni modo vedo che hai risolto.
Se vuoi approfondire, visto che comunque non e' chiaro perchè non 
funziona nel modo originale, qui trovi risorse piu' complete dove 
farlo:
http://info.borland.com/devsupport/sqllinks/tips.html
-- 
Morde

 ha scritto nel messaggio 
news:496c9c7f$1...@newsgate.x-privat.org...


 Il problema è rimasto irrisolto e incompreso.
Allora, chiariamoci: l'sql che usi con il vetusto BDE è un dialetto 
dell'sql creato da borland a suo tempo.. ed e' molto limitato in virtu' 
della tecnologia di allora. Non e' inusuale ne' impossibile pertanto 
che ci siano dei limiti insuperabili per certe interrogazioni.Per 
qualche motivo che non siamo riusciti a scoprire, la union non funziona 
con quelle tabelle.
QUINDI, hai due strade:
1) Continui a cercare la soluzione, studiando la tematica e provando 
ancora
2) Realizzi che il tempo speso e' gia' costato troppo per quella 
modifica, e quindi decidi di rientrare nei costi facendo un workaround.
Riguardo il punto 2, il workaround da me suggerito potrebbe esserti di 
aiuto: carica i dati in modo separato e, trattandosi di UNION, puoi 
pompare tutti i record dei dataset singoli in un unico CDS senza 
problemi visto che hai le stesse colonne per tutte le query.
Facci sapere come va.
Ciao
-- 
Morde

 i dbf hanno tutti la stessa struttura?

 contenuto non c'entra con il problema..
Scusate ma io non capisco questo passaggio.
In realtà secondo me è proprio il contrario, è proprio il contenuto
che crea problemi.
Quando esegui una sql i tipi delle colonne vengono dedotti dal
contenuto della colonna.
In questo caso il contenuto di una o più colonne delle due tabelle
inducono a pensare che i dati siano di tipo diverso e quindi "type
mismatch"
Per questo chiedevo dei dati null, perchè possono indurre a definire
una colonna di tipo diverso da quello che è realmente.
Prova a mettere i primi n record di "Africa.DBF" in "Italiani da
trovare.DBF" per verificare quello che dico io..
Matteo

 ha scritto nel messaggio 
news:ba1110d9-826e-4fe1...@r36g2000prf.googlegroups.com...


 ha scritto nel messaggio 
news:57d0bd4e-ff1f-4309...@a26g2000prf.googlegroups.com...


 ha scritto nel messaggio 
news:496a8706$0$1113$4faf...@reader3.news.tin.it...


 ricevuti mi sono sembrati utili comunque.
Bene :-)
-- 
Morde