1 2 Previous Next 17 Replies Latest reply on Aug 7, 2014 8:45 AM by lbellino

    Listing Items Vertically in a Portal

    lbellino

      Title

      Listing Items Vertically in a Portal

      Post

           Not sure if this can be done or not, but thought I would ask. Can fields be listed vertically in a portal instead of horizontally for data items for one record? Image attached shows four fields of data for one record for two departments. It would be nice to place all this information in one portal, if it can be done because currently for one store record I have in my database, could have up to 40 departments with these same fields. If it can't be done, that's fine. Just thought for spacing on my layout, that vertically might work better. 

           Any suggestions on how to make this better, especially for doing "finds" for reporting, would be much appreciated. Right now, I have in my layout just separate fields for each of these (no portals being used.) Thanks.

      dept_portal.jpg

        • 1. Re: Listing Items Vertically in a Portal
          philmodjunk

               What I see could be two records and thus two rows in a portal. You can drag a portal row selection handle down to make the row taller. (It's often better to temporarily set the number of portal rows to 1.) Then you can add layout text and reposition fields inside the now larger portal row to produce what you show in your screen shot.

          • 2. Re: Listing Items Vertically in a Portal
            lbellino

                 Let me see if I understand you correctly. I would create a separate table to house all these department ceiling heights and flooring types and each record would be associated by the store ID/number to create the relationship to show this data inside the portal I'm trying to create? If that's the case, what would be the primary key field for each of these areas? Can you have two within one table? I've done more than one foreign key fields, but have not done multiple primary key fields. If I'm totally off base here, sorry. 

                 Note: To explain these fields that I'm trying to populate in a portal, I do have them in a separate table from the main store table have it linked by store number. In this database, each record is a store number and these are attributes of a store.

            • 3. Re: Listing Items Vertically in a Portal
              philmodjunk

                   I do have them in a separate table from the main store table have it linked by store number. In this database, each record is a store number and these are attributes of a store.

                   So then can't you take a layout based on your store table and add a portal to this "separate table from the main store table have it linked by store number."?

                   Why would you need any other primary (or foreign) keys in order to make this happen?

              • 4. Re: Listing Items Vertically in a Portal
                lbellino

                     That's how I have it in the very first image I sent. In this image I've attached is how I have it currently set up as individual fields and wanted to put them in a portal, but doing it vertically, if possible. This is in the main store layout, but the data is being pulled already from another table of just store attributes, since we have around 500 of them, which is why they are in their own table, not that they needed to be, but my main store table already has a couple hundred fields already. 

                • 5. Re: Listing Items Vertically in a Portal
                  philmodjunk

                       I believe that you are receiving assistance with this in another thread here in the forum.

                       To set up a portal requires two table (occurrences) and a relationship that links them in a "one to many" relationship.

                       So to set up a table of "stores" and a table of "departments" where each department record stores information about that department for the store to which it is linked, I'd set it up this way:

                       Stores----<Departments

                       Stores::__pkStoreID = Departments::_fkStoreID

                       For an explanation of the notation that I am using, see the first post of: Common Forum Relationship and Field Notations Explained

                       __pkStoreID would, in most cases, be set up as an auto-entered serial number field. It might be the source of the number shown on your screen as a "store number" or it might be a different value all together.

                       With the above relationships in place, I can put a portal to Departments on a Stores layout. If I double click the relationship line between these two table occurrence boxes, I can select "allow creation of records via this relationship" for Departments and then I can add new related Departments records directly in the portal. If I enable the "delete" check box for Departments, any related records in Departments will be automatically deleted when the matching Stores record is deleted. This last option is powerful, but dangerous if set up incorrectly.

                  • 6. Re: Listing Items Vertically in a Portal
                    lbellino

                         I believe I get it. Based on the current data I do have in my table of attributes (this has every data for all the stores), would I move out the department data from this table into this new table so it can all show in the one portal that I'm trying to create?

                    • 7. Re: Listing Items Vertically in a Portal
                      philmodjunk

                           Exactly.

                           Take a look at Import Records as a way to move data from one set of "department fields" at a time into new records in the new table. Make sure that you have the __pk field defined and with values in it for every store first though. That way, you can import the value of the __pk field into the new table's _fk field as part of the import and thus the new records will be linked to your existing records.

                           Once you have all the data transferred and your portals are working, you can delete these department fields from the original table.

                      • 8. Re: Listing Items Vertically in a Portal
                        lbellino

                             I've done the importing of the __pk field (store number), which worked great and it brought in all my store numbers. So then I went onto the next step of importing the 8 fields I'm working with (for now) just to see if I can get this to work and when doing so, I matched it to the store number (which each store has it's own number), and what is shown in the image, is what I got. And I know all these fields are populated in the table where I took this info. from. If I don't do the match, it just brings in this data as new records and I still get the same result where the data is not populating. I'm making sure I'm taking it from the correct source and can't seem to figure out what I'm going wrong here. Sorry for all the questions, just don't want to screw up the data I currently have. Thanks for the help.

                        • 9. Re: Listing Items Vertically in a Portal
                          lbellino

                               The third column, which I will eventually turn off is the auto serial ID that I set up as the primary key, where as the store number (first column) is the foreign key.

                          • 10. Re: Listing Items Vertically in a Portal
                            philmodjunk

                                 Not quite how I was meaning for you to do this.

                                 You would import records 8 times for your 8 sets of department fields.

                                 You would create new records with every import.

                                 You would map the _pkfield in the source table to the _fkfield in the target table in every import.

                            • 11. Re: Listing Items Vertically in a Portal
                              lbellino

                                   Unfortunately, I had to export the data out to Excel to import each field data separately for this to work. Could not do it off the table where the data currently was held. But back to one of your earlier comments about the relationship setup:

                                   Stores----<Departments

                                   Stores::__pkStoreID = Departments::_fkStoreID

                                   For the data that I just imported into this Departments table. For this to work in the portal, do I have to assign a "department category" for each of those? I'm trying to get a portal to work and maybe because my brain is fried after trying to work on this all afternoon, I'm sure it's something easy that I'm missing, but can't seem to get it. I'm trying to do it to a similar post you mentioned I had earlier and since there's more fields I'm working with, not sure if I can do it the same way or not, since I'm not really doing a count, but rather just want to display the data I have in my database. Image shows the data I brought in, but when I do my portal, comes in the same way. I'm running out of time tonight, but will try again tomorrow to see if I can figure it out, but any help is much appreciated. Any way to do it better than how I have it, feel free to let me know. Thanks.

                              • 12. Re: Listing Items Vertically in a Portal
                                philmodjunk
                                     

                                          Unfortunately, I had to export the data out to Excel to import each field data separately for this to work. Could not do it off the table where the data currently was held. But back to one of your earlier comments about the relationship setup:

                                     That should not be the case. You go to a layout based on the new related table, select import records | File and then select the very same file that you have open from the open file dialog and then select the original table from which you want to import this data. (By selecting the layout based on your new table, you select the target table for your import.)

                                     If you want to identify each record by a department category, then you do need to assign a value to that field. Since it's not a value that you can import, you can import the data from one set of fields and then use Replace Field Contents to assign all the newly imported records the same value in the department category field.

                                • 13. Re: Listing Items Vertically in a Portal
                                  philmodjunk

                                       If I were importing this data, I would import the _kf field, and each of the 4 fields shown all in the same import, not a separate import for each field. This is why I described importing GROUPS of fields in each import.

                                  • 14. Re: Listing Items Vertically in a Portal
                                    lbellino

                                         I'll have to try this on my next department fields, since I already imported the data for Bath and Bedding before I got your latest response. Still doesn't explain how I can get my portal to read vertically (straight down), instead of it being staggered. Even straight across horizontally in the portal, would be fine too, if I could get that to work..

                                         Side Note: My other post that I was working with a portal and doing something similar to this where I wanted all my data into a new table, is having the same importing issue. Following your instructions to import records into this new table from the table where the data is housed that I need to copy over, the store numbers (which is the specific ID that I'm working with that everything is linked to) not all the store numbers are coming in, but the data is for them. See image attached. I'm importing from the correct table where this data is housed. I could try importing all the stores and match it, but not sure if this would solve the issue or be the better option. 

                                    1 2 Previous Next