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?

Improve this question
3
  • 4
    Seems more a problem in that "GUI" rather than an Oracle problem.
    – user1822
    Jan 25, 2013 at 9:20
  • How did you do the "migrated the database tables from a latin to unicode character set" part?
    – Mat
    Jan 25, 2013 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, 2013 at 17:37

1 Answer 1

Reset to default
1

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

Improve this answer
1
  • Thanks - perhaps there are relevant triggers on the table.
    – Julian
    Sep 7, 2016 at 18:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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