Newsgroup: it.comp.lang.visual-basic
Titolo: [HELP] Errore -2147417848 in VB6sp5

Da quando ho cambiato S.O. (da win2K a winXP) un programma continua a darmi
questo errore (Errore di automazione. L'oggetto invocato si è disconnesso
dai client corrispondenti) premesso che in precedenza non aveva mai dato
problemi, darei colpa al S.O....
ho provato lo stesso programma su win98  e un altro win2K e funziona bene.
Il problema si verifica quando lancio due query (solo 2 su di una trentina
in totale) su di un db Oracle.
La stringa sql è corretta (intercettata via codice e rilanciata tramite
sql*plus).
Su web ho trovato un po' di accenni e sembrerebbe che fosse qualche dll o
ocx ma non capisco perchè allora funzionino le altre query e non so come
identifcarla.
qualcuno mi può aiutare?
grazie
-- 
Un uomo senza pancia
è come un cielo senza stelle

 bene.
Ce n'è un po'...
http://makeashorterlink.com/?P500159D7

 
http://makeashorterlink.com/?P500159D7
non mi sembra che ci sia quello che mi serve... cmq ci darň una occhiata piů
attenta...
il pezzetto di codice che mi genera l'errore č questo:
Dim goSession As Object
Dim goDb      As Object
Dim sTmp As Object
Set goSession = Nothing
Set goDb = Nothing
Set goSession = CreateObject("OracleInProcServer.XOraSession")
Set goDb = goSession.DbOpenDatabase(Servizio, Utente& "/" & Password, 0&)
ssql="select ... from... where ..."
Set oTmp = goDb.DbCreateDynaset(sSql, 8&)                  'QUI   Mi genera
l'errore!

 Set oTmp = goDb.DbCreateDynaset(sSql, 8&)                  'QUI   Mi
genera l'errore!
Questo č certamente (insieme a DbOpenDatabase) un metodo specifico e
proprietario. Ti consiglierei di approfondirne l'analisi.

 proprietario. Ti consiglierei di approfondirne l'analisi.
hai ragione ma le altre query (lanciate sempre dalla stessa applicazione
funzionano bene)
e queste query, eseguite tramite il prog, da altri pc win2k/win9x funzionano
:(
grazie cmq
ciao

 applicazione funzionano bene)
Un motivo in più per postare proprio ciò che hai omesso, non trovi?
Ciao
Alberto

 funzionano :(
Se cerchi in questo NG troverai un mio post in cui una serie di query
(nemmeno una sola e pesante, ma tante e piccole) mandava in timeout
nientepopòdimeno che SQL Server. Il resto dell'applicativo (99.9999%)
funzionava. Quindi, cosa vogliamo dedurre?

 funzionava. Quindi, cosa vogliamo dedurre?
che il 99,999% del programma aveva qualcosa di strano.
-- 
Salutoni
Sergio
per rispondere... togli il group dall'indirizzo

 che il 99,999% del programma aveva qualcosa di strano.
Vabbč, mi astengo, anch'io, dal mettere faccine...

> Un motivo in più per postare proprio ciò che hai omesso, non trovi?
ok eccola qui:
********* inizio
select * from (SELECT m.NUM_ESER_CONT, m.CDA_POLO_NUM, m.CDA_SERIE_NUM,
m.PRG_DOC, m.prg_part_doc,m.CDA_CDC_COS,
m.DAT_COMP_DA, m.DAT_COMP_A,
t.dat_doc, M.Cda_Voce_Cos , to_char(m.VAL_MOVIM_NETTO,'9G999G999G990D99'),
decode(to_char(m.DAT_COMP_DA,'yyyymm')-to_char(m.DAT_COMP_A,'yyyymm'),0,'OK'
,'Da Verificare!') stato
from MGXX_DOCRIGA m, CDXX_VOCECR, ctrl_vocipdc_soloprimolivello, cgxx_conti,
mgxx_doctest t, mgxx_docpartita p
WHERE m.flg_canc_logica=0
and t.flg_canc_logica=0
and p.flg_canc_logica=0
and m.cda_tipoartmov<>'RD'
and t.cda_stato_doc='SPE'
and m.CDA_VOCE_COS=CDXX_VOCECR.CDA_VOCE(+)
and
substr(CDXX_VOCECR.CDA_VOCE,1,2)=ctrl_vocipdc_soloprimolivello.CDA_VOCE(+)
and ctrl_vocipdc_soloprimolivello.CDA_CONTO=CGXX_CONTI.CDA_CONTO(+)
and t.dat_doc between '01/gen/2004' and '26/mar/2004'
and m.CDA_TIPO_DOC_NUM In ('OF','OP','OL','OB','OE','OS')
and m.CDA_POLO_NUM=p.CDA_POLO_NUM
and m.CDA_TIPO_DOC_NUM=p.CDA_TIPO_DOC_NUM
and m.NUM_ESER_CONT=p.NUM_ESER_CONT
and m.CDA_SERIE_NUM=p.CDA_SERIE_NUM
and m.PRG_DOC=p.PRG_DOC
and m.PRG_part_DOC=p.PRG_part_DOC
and p.CDA_POLO_NUM=t.CDA_POLO_NUM
and p.CDA_TIPO_DOC_NUM=t.CDA_TIPO_DOC_NUM
and p.NUM_ESER_CONT=t.NUM_ESER_CONT
and p.CDA_SERIE_NUM=t.CDA_SERIE_NUM
and p.PRG_DOC=t.PRG_DOC)
where stato<>'OK'
*************** fine
ripeto comunque che la query funziona su tutti gli altri S.O. ed anche sul
mio (anche se lo devo lanciare tramite oracle)
ciao

> Bene. Allora, visto che non vuoi raccontarcela, affidati ad Oracle, no?!
:)
vabbè via, ve l'ho "raccontata" anche a voi...
è in risposta al messaggio di AlbeV°
ciao

 and t.dat_doc between '01/gen/2004' and '26/mar/2004'
Questo pezzo come lo generi?
Alberto

 Questo pezzo come lo generi?
inserito a mano e convertito nel formato nativo del server oracle


E cosa significa?
Ascolta, JtS, ci sono due possibilità:
O vuoi essere aiutato, e secondo me, da come mi hai risposto, siamo sulla
strada di trovare il problema, e allora devi postare il codice.
Oppure stai scrivendo per il puro gusto di riempire la banda, e allora puoi
proseguire a fare il misterioso.
'Inserito a mano'...
Cioè, ogni volta scrivi tutta la query in un textbox?
Io ritengo più probabile che tu faccia qualche concatenazione di stringhe,
giusto?
Dopo che avrai postato, ragioneremo su quello che tu chiami il 'formato
nativo di Oracle', sul fatto che stai usando un formato localizzato, sul
fatto che diversi utenti Oracle possano avere localizzazioni diverse, sul
fatto che diversi SO abbiano localizzazioni diverse, ecc...
Ciao
Alberto

 Vabbè, mi astengo, anch'io, dal mettere faccine...
mi parevano sprecate.
però...
però...
se ammettiamo che la statistica è un'opinione...
se consideriamo che un'applicazione è una unità inscindibile...
poche balle: il tuo programma non funzionava al 100%


 fatto che diversi SO abbiano localizzazioni diverse, ecc...
la localizzazione viene sempre impostata (da programma) sulla lingua
italiana con la "," come separatore dei decimali e con il punto per le
migliaia tramite
    goDb.ExecuteSQL "ALTER SESSION SET NLS_Date_Format=""dd/mon/yyyy"""
    goDb.ExecuteSQL "ALTER SESSION SET NLS_Date_Language='ITALIAN'"
ciao

 poche balle: il tuo programma non funzionava al 100%
Beh?! E io cos'ho detto? Che funzionava al 99.9999%.
Come ho risolto? Non ricordo, ma c'entrava ADO.

     goDb.ExecuteSQL "ALTER SESSION SET NLS_Date_Language='ITALIAN'"
dimenticavo
    goDb.ExecuteSQL "ALTER SESSION SET NLS_Numeric_Characters='.,'"

nella query il problema non è il formato delle date (ho escluso la riga del
filtro si di esse ed il problema esiste ancora)
ciao

 Come ho risolto? Non ricordo, ma c'entrava ADO.
ecco, è sempre colpa sua...


 ecco, è sempre colpa sua...
No, ma spesso.

 Ok, mi ritiro in Cina, dove, almeno, non ci sono i sindacati...
e hanno anche un solo partito.
non č l'optimum, ma dovrebbe essere gią un miglioramento.


  goDb.ExecuteSQL "ALTER SESSION SET NLS_Date_Language='ITALIAN'"
Beh, questo nel codice che avevi postato non lo vedo.
Visto che la Session viene creata un attimo prima di eseguire la Select, le
due righe qui sopra devono esserci, fra il OpenDatabase e il CreateDynaset.
Se non le esegui prima della select, il formato locale assegnato all'utente
dipende da una serie di cose del server, del login e della session.
Prova a inserire, giusto per provare, le date in formato universale
yyyymmdd, e dimmi se cambia qualcosa.
Ciao
Alberto

 yyyymmdd, e dimmi se cambia qualcosa.
ho scluso il filtro sulle date e da' ancora lo stesso errore (vedi il post
[Aggiornamento])
ciao

 post [Aggiornamento])
non so come funziona il Collate in Oracle, e non entro nel merito di tutti
quei join che potrebbero richiedere qualche conversione implicita.
Comunque il tuo approccio è ad alto rischio. Se dopo aver creato una Session
non esegui subito le tre righe contenenti l'alter_Session, sei in balìa di
una serie di settaggi che possono differire da utente a utente (e quindi
anche da pc a pc).
Una cosa che non so esattamente come funzioni in Oracle, per cui non vorrei
dire una cavolata, è quel Decode in cui utilizzi due valori stringa di
lunghezza diversa (OK e Da Verificare!). Prova al limite ad aggiungere dei
puntini dopo OK, per avere la stessa lunghezza.
La cosa che dovrebbe far pensare, e che mi rafforza nella mia opinione che
si tratti di impostazioni di accesso, è che la stessa stringa eseguita nel
CreateDynaset non funzioni, mentre da consolle Sql si.
Ciao
Alberto

 CreateDynaset non funzioni, mentre da consolle Sql si.
in effetti credo sia dovuto alla nuova configurazione della macchina su cui
non ho piů accesso
in quanto sono cambiate le politiche di gestione della rete in azienda e non
si č piů
completamente amministratori del pc... quindi non so bene cosa e come mi
hanno configurato il pc
vabbč...
ti ringrazio per il tempo perso e ti auguro buon lavoro
ciao

 mi hanno configurato il pc
Appunto.
Il tuo modo di operare è a rischio 'configurazione'. Siccome esistono
tecniche che permettono di interagire con i dbms in maniera del tutto
indipendente dai settaggi di client, server, login, rete, ecc..., esporsi a
queste cose è un rischio inutile.
Ciao
Alberto

> A me sembra che sia fra i campi da estrarre, non nel where...
ho scoperto la causa: si tratta di una incompatibilità fra il server oracle
(versione 8.1.7) e il client (versione 9.2.0.1)
grazie lo stesso
ciao