Brian Tkatch wrote:Without an ORDER BY clause, the database will just return what it wants, which may just be what's currently stored in the cache.
As an aside, the query uses SELECT *, which really is best for EXISTS() and ad hoc queries. In normal code, spelling out the column names is self-documenting, and good protection against column changes.
John Francis Ochotorina wrote:Hi! Thanks for responding. I tried to add in my query the ORDER BY.
When I run this to the query it's giving me the correct ascending value. But when I run the program still giving me the last inserted
Brian Tkatch wrote:
John Francis Ochotorina wrote:Hi! Thanks for responding. I tried to add in my query the ORDER BY.
When I run this to the query it's giving me the correct ascending value. But when I run the program still giving me the last inserted
searchSECTIONSETTINGS has no parameters, though, i am confused by the ticks (`SECTION_ID`). I am not sure what those are for.
Are you saying that mySecondPs.executeQuery() only returns one record, and mySecondRs.next() returns false the after it?
John Francis Ochotorina wrote:My ResultSet returning false and giving me a last values in my database. Yes only returns one record. Thanks for responding
Brian Tkatch wrote:
John Francis Ochotorina wrote:My ResultSet returning false and giving me a last values in my database. Yes only returns one record. Thanks for responding
So, the same exact query returns a different number of records depending on it being run from your code or from the database itself? That seems strange.
One idea is that there are uncommitted records in the current database session, but not viewable from the java code. To remedy that, issue a
Another idea is the code is using a different database. Can you verify the code-added record is viewable in the database session?
Brian Tkatch wrote:Autocommit is fine, i guess. This isn't a comment on the code inasmuch as it is a comment on the database sessions. We need to verify the same data is visible in both sessions. (The database connection where you run the query and see all the data, and the java code session, created when running the code.) And while we're at it, that both are connected to the same database.
John Francis Ochotorina wrote:
Martin Vajsar wrote:I guess that the problem lies here:
John Francis Ochotorina wrote:
This loop goes through all records in the resultset, and calls setSelectedItem on individual combo boxes. Note that setSelectedItem doesn't add new item into the combo box's list, it just sets the text in the combo box.
Let's say that there are N records returned by your query. On the first execution of the body of the while loop, the combo boxes are set up with the texts contained in the first record. On the second execution, the cmbo boxes are set up with the texts contained in the second record - setSelectedItem overwrites what was there before. And so on for the third, fourth, ... Nth record.
The loop terminates when all records are processed, leaving your combo boxes set to the contents of the last record. For simple SELECT queries, databases sometimes (not always) return rows in the order in which they were inserted to the database - therefore you always end up with values from the last record in your combo boxes. Note: if you want to obtain rows in a specific order, always use the ORDER BY clause to specify that order.
If you want your combo boxes to contain all of the records returned by the query, use the addItem or insertItem method - see Javadoc.
John Francis Ochotorina wrote:When I try to Select a record using Prepared Statement it always giving me a last inserted values that I recently add.
First what did I do is to search a record in my first table. If the record is exist the foreign key table will populate the values. My Primary and Foreign Key tables works well. The values populating appropriately to their corresponding components but it's not giving me the right values. Any help?
John Francis Ochotorina wrote:As you can see here. In my first ResultSet myFirstRs when I search a existing SECTION_NAME the foreign key values will populate.
Roel De Nijs wrote:
John Francis Ochotorina wrote:When I try to Select a record using Prepared Statement it always giving me a last inserted values that I recently add.
First what did I do is to search a record in my first table. If the record is exist the foreign key table will populate the values. My Primary and Foreign Key tables works well. The values populating appropriately to their corresponding components but it's not giving me the right values. Any help?
You should always explain first what you are trying to achieve. And then you can share code snippets about how you have implemented it. Currently I am and have no clue about what you are trying to achieve. The code snippets you have posted and the screenshots you have shared seem to contradict each other.
So you have a query searchSECTIONNAME which seems to be a prepared statement (which is great ) and searches a table based on the section name. If I look at your code, you search for a section using the value provided in the Section_SearchSection_Textfield. Then you get the section name from this result set to fill up the Section_SectionName_TextField in your GUI. And then you execute your second query searchSECTIONSETTINGS. But this query is not parametrized at all! So you will always return all records from table allsections_settings and not only those from the section you have just searched for (and what seems to be expected, why would you otherwise let the user search first for a section ).
Then it seems you are expecting more than one record as you are using a while loop to iterate through the result set, but you are displaying the results in a bunch of seperate combo boxes. And in my opinion that makes no sense at all! And updating a record will be very, very, very hard for a user. If you want to display multiple records from a search, you would expect to see a JTable with different columns. If you want to update a record, you could double click on that record (or click on an Edit button) and then you could have a seperate update dialog (or if you are really brave an editable JTable).
Finally I have two remarks about your code quality:
1/ don't use indexes when retrieving results from your result set. If you are re-arranging your columns in the SELECT clause of your query, you'll introduce hard to find bugs
2/ try to follow Oracle's code conventions and don't use underscores in variable names (only use them for constants)
John Francis Ochotorina wrote:As you can see here. In my first ResultSet myFirstRs when I search a existing SECTION_NAME the foreign key values will populate.
Honestly I don't see at all where the foreign key values of your first query are populated. If you completely remove everything related to the first query and result set, your second query and result set will produce exactly the same outcome!
Hope it helps!
Kind regards,
Roel
John Francis Ochotorina wrote:My question is when I search a existing record in my Primary Key table, I want the referencing table which is Foreign Key table will populate the values of the `Section_Name` that I select. How can I determine if I'm getting the right values? If there's something wrong with my code or condition?
Roel De Nijs wrote:There is no such thing as a primary key table, because in a RDBMS any table should have a primary key.
Roel De Nijs wrote:Because a primary key is the unique identifier for each row.
Brian Tkatch wrote:A couple side points.
Brian Tkatch wrote:While it is normal to have a primary key, it is most certainly not required.
Brian Tkatch wrote:You ought to remove the word "the" from that statement.
Roel De Nijs wrote:
Brian Tkatch wrote:A couple side points.
Have a cow for those lovely side points!
Roel De Nijs wrote:
Brian Tkatch wrote:While it is normal to have a primary key, it is most certainly not required.
That's why I used "should" and not "must"
Brian Tkatch wrote:or "usually should." Should on its own seems likely always, which is not the case.
Dave Tolls wrote:
Brian Tkatch wrote:or "usually should." Should on its own seems likely always, which is not the case.
Well, in Java it would be "likely always", especially with ORM frameworks.
They get a bit grumpy without them.
Brian Tkatch wrote:Though, i would further change "should" to "should probably" or "usually should." Should on its own seems likely always, which is not the case.
Roel De Nijs wrote:
Brian Tkatch wrote:Though, i would further change "should" to "should probably" or "usually should." Should on its own seems likely always, which is not the case.
In my vocabulary (and understanding) of the English language (as a non-native English speaker who scored poorly on English during secondary school ), "should" doesn't imply "always". If I want to express "always", I would use "must" or "is required" or explicitly mention "always" in the sentence. But according to Google Translate, my understanding is wrong indeed and therefore I have to be careful when using the word "should" Probably "may" or "might" would have been a better choice of words in that sentence. Regarding a mock question in one of the study guides, there was a similar (fairly lengthy) discussion about the difference between "allowed" and "required".
Brian Tkatch wrote:
Dave Tolls wrote:
Well, in Java it would be "likely always", especially with ORM frameworks.
They get a bit grumpy without them.
I hate frameworks. TopLink is also stupid and evil.
Dave Tolls wrote:
Brian Tkatch wrote:
Dave Tolls wrote:
Well, in Java it would be "likely always", especially with ORM frameworks.
They get a bit grumpy without them.
I hate frameworks. TopLink is also stupid and evil.
The likes of Hibernate have, by and large (and with the odd caveat) made my life a lot easier when it comes to your standard web app.
Dave Tolls wrote:Possibly, but then I don't remember producing Oracle dbs that didn't have PKs on all their tables, so maybe it was less of a stretch for me.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Trust God, but always tether your camel... to this tiny ad.
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|