probleme oracle11gr2 si access97

[pitzy]

Dupa un upgrade de la Oracle 9i la Oracle 11G R2 aplicatiile access97 ce aceeseaza baza de date (linked tables) au un comportament ciudat:
Daca introduc intr-un camp al unei inregistrari valarea 6,78 de exemplu, totul e normal. Daca introduc in acelasi camp valoarea 6,77 atunci nici un alt camp al inregistrarii respective nu mai poate fi editat si primesc mesaj de eroare.

Eroarea este asta:

This record has been changed by another user since you started editing it. If you save the record, you will overwrite the changes the other user made.

Copying the changes to the clipboard will let you look at the values the other user entered, and then paste your changes back in if you decide to make changes.

 

[miahi]

Ai upgradat si driverul ODBC?

Ai un server de Oracle de development, pe care poti sa faci ce vrei, cum ar fi trace la toate sesiunile (caz in care ar fi bine sa fii singur pe server)?

 

[pitzy]

am pus ultimul driver ODBC de la oracle 11.2.... Am incercat cu drivere mai vechi cu drivere microsoft. Acelasi rezultat. Am facut trace pe sesiuni, sunt singurul user care acceseaza schema respectiva.
Daca folosesc Access2007 problema dispare; cu conditia ca Access97 sa fie dezinstalat , altfel problema se repeta in ambele instante (97 si 2007). Deocamdata iese din discutie upgrade-ul de Access pentru ca apar alte probleme mai mari la nivel de aplicatie

 

[miahi]

Am facut trace pe sesiuni, sunt singurul user care acceseaza schema respectiva.

Ok, dar ce încearcă să execute Access-ul atunci când îți dă eroarea? Pentru că probabil el încearcă să verifice că mai există înregistrarea înainte să facă update, sau face update-ul cu where ... din câmpurile existente, și ceva nu-i place. Dacă ești singur pe server poți să dai trace doar la sesiunile tale, dar pune neapărat și binds.

EXECUTE DBMS_MONITOR.SESSION_TRACE_ENABLE (session_id => ___, serial_num => ___,waits => TRUE, binds => TRUE);

iar ca să găsești fișierul unde scrie

select p.tracefile from v$session s, v$process p where s.sid=___ and s.paddr=p.addr;

Faptul că Access2007 merge doar dacă e 97 dezinstalat sună tot a versiune de ODBC sau altceva din Access. Probabil castează incorect un câmp, și când îl caută pentru update îi dă cu virgulă (la propriu).

 

[pitzy]

Pe trace-uri nu apare absolut nimic anormal. Nu le am la indemana acum, ca le-as arata.
M-am gandit si eu ca ar fi o problema cu conversia datelor inspre sau dinspre Oracle (doar la valorile numerice cu virgula apare problema; nu la toate , am identificat vreo 3: 6,77;103,5, 6,89). Probabil face o trunchiere undeva si cand access-ul verifica campul inainte de update gaseste altceva decat stia ca trebuie sa fie.
Dar nu imi dau seama cum sa evit problema.
Daca fac un querry sql simplu, prin Access97, update-ul merge ca uns.

A, uitasem sa zic. Update-ul campului cu valorile problema se face cu succes. Nu mai pot edita alte campuri (nici pe el) dupa.

 

[miahi]

Ai identificat în trace-uri select-ul sau update-ul pe care îl face înainte să dea eroarea?

Ai putea să te joci un pic cu tipul coloanei, să vezi ce se întâmplă dacă-i schimbi precizia și scala.

 

[pitzy]

hai ca o sa pun trace-ul cand reusesc sa il iau ca acum nu sunt la servici.
cu tipul coloanei o sa ma joc luni. Acum e Number 14 cu 2. In access97 o vede double si in 2007 o vede decimal.

 

[miahi]

In access97 o vede double

Păi de-aia. Double e floating point, poa' să interpreteze oricum. Probabil între timp s-a schimbat modul de rotunjire la 2 zecimale pe undeva prin drivere.

LE: Release notes din driver-ul ODBC:

In general to avoid precision problems using ODBC, ensure that data stored in the Oracle database for a double data type conform to the specifications described in the Microsoft ODBC Programmer's Reference and SDK Guide.

 

[pitzy]

Sa inteleg ca tre buie sa setez coloana la o precizie de maxim 15 digits ca sa nu se mai faca rotunjire? Acum precizia e 14 (<15) si scala 2. Chiar nu-mi dau seama unde ar trebui sa umblu.

 

[miahi]

Ideea e să convingi Access97 să nu folosească double pe coloană, ci decimal. Nu știu cum trebuie făcut, n-am mai lucrat cu Access de pe vremea... Access97.

E interesant că problema apare și în Access 2007 atunci când ai instalat Access97, înseamnă că 97 instalează niște biblioteci (posibil o versiune de ODBC) pe care 2007-le nu le updatează, folosește ce e deja instalat. Și acea bibliotecă are problema de incompatibilitate cu noua versiune de Oracle.

 

[puterfixer]

Am avut probleme cu versiuni diferite de Access instalate pe același calculator: ultima versiune instalată suprascria componente ale celeilalte versiuni. Conectivitatea la baze de date remote avea de suferit, și unele controale nu mai funcționau corect în aplicațiile celeilalte versiuni. Iar în ceea ce privește conectarea la servere de baze de date, bug-uri erau gârlă în versiunile '95-'97-2000; uneori trebuia să delinkăm tabelele și să le reconectăm ca să meargă, făceam cast-uri explicite de tipuri de date (gen converteam o valoare float într-o variabilă float care să fie scrisă într-un câmp float) și alte ciudățenii de-astea. La unele probleme întâlnite, Microsoft chiar avea publicate articole pe KB, cu recomandarea unui upgrade. De-abia în Access 2003 și 2007 a început să funcționeze previzibil și eficient.

Nu sunt convins că este justificat efortul de a restaura compatibilitatea dintre o aplicație Access atât de veche cu un server de baze de date nou. Deși e mai mare bătaia de cap, upgrade-ul tehnologic ar trebui să se facă în toate componentele aplicației, inclusiv o portare pe Access 2007 cel puțin (ideal 2010 sau ăla mai nou dacă a apărut).