Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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';


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?

share|improve this question
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

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.