Buongiorno a tutte/tutti.
Ho un problemino che non riesco a risolvere su un'applicazione per dwh con interfaccia utente VB, motore OLAP (sempre VB, credo) inaccessibile (Dynamicube, della Datadynamics, ma se non si puo' dire, cancellate pure i riferimenti ai prodotti commerciali).
L'interfaccia utente (quella che da modo anche di accedere alle viste e tabelle sul db) e' scritta in VB (attualmente compilata con vb 6.0) ed accede, a seconda della scelta, via odbc, ado, oledb, ad un db sqlserver2000.
Il problema (a parte me, che non ci capisco un piffero di vb e programmazione su piattaforme piccole, ed ho appena cominciato a capire qualcosa di sqlserver) e' legato alle somme dei campi numerici.

Tutti gli importi sono definiti, sul db, come decimal(18, 2), a parte alcuni valori unitari che sono decimal(18, 5).

Tutti i dati, estratti da ETL cobol/db2, che girano sotto s/390 estraggono e fanno caricare i dati con il corretto numero di decimali.

Alcuni cubi, all'atto del drill-up, mostrano gli importi, comunque con 6 decimali e, cosa ancor piu' strana, inventandosi le cifre a partire dalla 3° dopo la virgola in poi.
Ad esempio, sommando i valori tipo:
12,34
.etc..
.etc..
98,87
ottengo un risultato tipo 123,456789.
Questo stupisce :master: sia me che, soprattutto, gli utenti.

Tenendo conto che non posso cambiare il codice VB adattandolo ad ogni singolo cubo (anche perche' l'utente puo' cambiarsi i cubi a suo piacimento e realizzarne di nuovi), come posso risolvere il problema?

Qualcuno mi ha detto che VB prende la definizione del campo dal DB (con una sua funzione che mi hanno mostrato) ma che, per sua natura, considera i campi decimal, comunque con almeno 6 decimali, per cui dovrei cambiare il datatype sul db(ma prima di farlo volevo qualche certezza), da decimal a non mi ricordo piu' quale datatype.

Qualcuno saprebbe dirmi qualcosa al riguardo?

Grazie,
Andrea

P.S.: Dimenticavo un particolare che, forse, puo' essere utile: le query vengono scritte interamente dal motore OLAP (quel componente blindato).