2

We have a thick client application using an Oracle 10g database. We recently upgraded the application and in the process migrated the database tables from a latin to unicode character set.

After the upgrade some fields behaved 'read only' from the GUI screens. We found that we had some wrong values and updated them using an SQL command line tool and these fields suddenly became editable in the application.

So we updated the fields for all the rows and the problem disappeared completely.

The two queries we used were:

update listings_text set text = 'Y' where text = 'y';

and

update listings_text set text = text;

Now the second query should be a noop. But its not. Can anyone explain why this query might have an effect?

  • 4
    Seems more a problem in that "GUI" rather than an Oracle problem. – a_horse_with_no_name Jan 25 '13 at 9:20
  • How did you do the "migrated the database tables from a latin to unicode character set" part? – Mat Jan 25 '13 at 10:58
  • The character set migration was done by creating a new database with the unicode definitions and exporting from the old database and importing into the new one. Little of the text was non-ascii. Yes - its a GUI related issue, but the GUI behave differently after that update. I guess there could be an auto-update field or something involved - the GUI can tell the difference before and after the 'noop' somehow. – Julian Jan 25 '13 at 17:37
1

The "noop" would have fired any related triggers on the table, and it would have advanced the system change number.

  • Thanks - perhaps there are relevant triggers on the table. – Julian Sep 7 '16 at 18:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.