|
Robert, I agree with your statement for an update of a record. I do need something unique. Here is some more information about the issue. In the JSF tutorial I found in WSAD, the record list control gave me the entire record contents. From that record, I passed the unique key to an update JSP. The update JSP used the unique key to get the record for update purposes. If I can update records from my list of records JSP, I would need a unique key. I think I should have a choice on whether my JSP will be used for update or not. -----Original Message----- From: wdsci-l-bounces+mjfasnacht=carlsoncraft.com@xxxxxxxxxxxx [mailto:wdsci-l-bounces+mjfasnacht=carlsoncraft.com@xxxxxxxxxxxx] On Behalf Of Dean, Robert Sent: Wednesday, October 27, 2004 5:51 PM To: Websphere Development Studio Client for iSeries Subject: RE: [WDSCI-L] Java Server Faces Relational Record List I'm not from IBM, but I can venture a guess as to what's going on behind the scenes. The tooling probably wants a unique key in case you would want to perform updates on it. If you update one of the ten records, how will it look up the record to update? It would expect you to tell it which fields uniquely identify each record. -----Original Message----- From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx]On Behalf Of Fasnacht, Mike J Sent: Wednesday, October 27, 2004 6:21 PM To: 'Websphere Development Studio Client for iSeries' Subject: RE: [WDSCI-L] Java Server Faces Relational Record List Dear IBM, Help me see the light. Maybe it's just that I am a RPG programmer trying to figure out Java. Assuming FILEA has 10 records for customer number 5, when I run this statement SELECT * FROM FILEA WHERE CSTNUM = 5 I should get 10 records. When I run this statement using a relation record list in JSF, I get 1 record. This is what I found to get around my problem with the relational record list control in JSF. The relational record list is fetching only the unique values from the table. Example: If I want all the records that match a customer number, I have to define a 2 part unique key to get the entire list. Through the relational record list wizard I have to define my primary key to the file as being customer number and invoice number to get the previous SQL statement to return all the records instead of just one. What in Tarnation is going on? Can anyone at IBM explain this to me? -----Original Message----- From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Fasnacht, Mike J Sent: Friday, October 22, 2004 9:30 AM To: 'Websphere Development Studio Client for iSeries' Subject: RE: [WDSCI-L] Java Server Faces Relational Record List Some more detail. When I run the SQL statement through the data perspective, I get the same six records. Also, I am connecting to an iSeries using jt400.jar -----Original Message----- From: wdsci-l-bounces@xxxxxxxxxxxx [mailto:wdsci-l-bounces@xxxxxxxxxxxx] On Behalf Of Fasnacht, Mike J Sent: Thursday, October 21, 2004 5:11 PM To: 'wdsci-l@xxxxxxxxxxxx' Subject: [WDSCI-L] Java Server Faces Relational Record List Hello all, I'm trying to build a sample app using Java Server Faces. I am trying to use a relational record list. After completing the wizard to tie the relational record list to a database, I run it on the server and only get one record when I am expecting 6. Here are the details Using WDSc 5.1.2 Using WebSphere v5.1 Test environment The SQL statement listed in the console looks like this. SELECT LIB.PGMDOCPF.PDTYPCDE, LIB.PGMDOCPF.PDNAME, LIB.PGMDOCPF.PDLIB, LIB.PGMDOCPF.PDUNIQUE, LIB.PGMDOCPF.PDCODE, LIB.PGMDOCPF.PDSEQ, LIB.PGMDOCPF.PDINFO FROM LIB.PGMDOCPF WHERE ( PDTYPCDE = '*PROC' AND PDUNIQUE = 1 AND PDCODE = 'NAME') ORDER BY PDLIB ASC, PDNAME ASC The SQL statement looks legit. When I modify the SQL statement to allow for a larger record set, it comes back with the first instance of each unique PDTYPCDE and PDCODE combination. What am I overlooking? Is there some setting that limits the list to the first instance of each record with the keys I'm looking for? Has anyone come across this issue? Michael J. Fasnacht Wedding and Greeting Entrepreneurial Business mjfasnacht@xxxxxxxxxxxxxxxx <mailto:mjfasnacht@xxxxxxxxxxxxxxxx> Ph. (507) 625-0893 Fax (507) 386-2307 _______________________________________________ This is the Websphere Development Studio Client for iSeries (WDSCI-L) mailing list To post a message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/wdsci-l or email: WDSCI-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/wdsci-l. _______________________________________________ This is the Websphere Development Studio Client for iSeries (WDSCI-L) mailing list To post a message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/wdsci-l or email: WDSCI-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/wdsci-l. _______________________________________________ This is the Websphere Development Studio Client for iSeries (WDSCI-L) mailing list To post a message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/wdsci-l or email: WDSCI-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/wdsci-l. _______________________________________________ This is the Websphere Development Studio Client for iSeries (WDSCI-L) mailing list To post a message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/wdsci-l or email: WDSCI-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/wdsci-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.