Thank you for the post. I found it very interesting for me as Oracle DBA.
Thank you for the post. I found it very interesting for me as Oracle DBA.
Banner for DOAG Konferenz und Ausstellung 2025 vom 18. bis 21. November
Finalized my #DOAG2025 slides for the DOAG conference next week. Happy to be in Nuremberg again.
Wo ist denn das genau, zwischen Questenberg und Hainrode?
Ein korrektes SQL heiΓt aber nicht ein korrektes Abfrageergebnis. Solange die KI nicht auf dem abgefragten Datenmodell trainiert ist, wΓΌrde ich die Ergebnisse mit groΓer Vorsicht genieΓen
Being in Poznan, try "rogal ΕwiΔtomarciΕski", very delicious and sweet.
Hi, thanks for the info. I checked the note and it does not apply for me. The database was a < 19c one (at the time the insert occured) on Solaris-Sparc. The client was running a 64bit JVM on RHEL (Intel no AMD).
The "corrupt" number values were written into the database many years ago and we think that a issue with the version of JDBC driver and version of database caused the issue. But we were not able to reproduce. It was possible to insert the corrupt data into a different DB using DB-Link.
Hello,
a datapump-export/import of the affected table gave also the invalid number errors during import. I raised a SR with, but it ended in an endless loop (SQL isssue or data corruption ping-pong). At the end we did an update of the number field with a rounded value,
Hello, had a very similar case, JDBC returned a number value, but a select with SQL-Plus gave an invalid number. Have you tried with a round(<number>, <try starting with 1>)? In my case something was wrong with the very last digits of the affect number rows/fields.
I would appreciate it.