This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
Hi ALex, Let me just chew on this for a while. A non-indexed table? Do I get you correctly to mean a table containing duplicate rows? If so, you can still index the table, but it will not be a uniqie index . Anyways, I think you can easily get to a row's position in the ResultSet (getRowNum(), wasn't it). If you store that value with the other row data, you 'll always know what row you 're dealing with . Good riding, Rudy.
Joined: Jan 24, 2001
Well, the reason the table is not indexed is because the table structure at my work is STUPID. But as you say if I am going to use getRowNum(), and try to delete record where more than one record is the same wouldn't it delete all the same records? Or should I just see if getRowNum() is more than 1 and delete any one of those?
Joined: Jul 27, 2002
Hi Alex, Now that 's a different ball game, isn't it? Just now we were talking about browsing through a ResultSet, and already we 're out to delete records. That does require a bit more caution, obviously. Clearly you 're on a very risky track if you try and delete a record that satisfies some criterion. There may be more than one, as you state. Some implementations of ResultSet allow you to delete given rows in the set, and commit this to the underlying database, but I never worked with it. I wouldn't know whether that 's a good solution or not. It seems to deal with your uniquiness problem, I would say. Oh, by the way, I don't follow your remarks on the getRowNum() function. It seems you have a different idea of what it does. In this case I 'll join one of the regulars here in saying: 'Javadoc is your friend'. Stay late and you might meet him. He 's a bit talkative at times, but he might learn you a trick or two. Say hello from me when you meet him in the saloon. Good riding, Rudy.