I'm an A5v9 newbie, coming from . . . wait for it . . . Paradox for DOS. For the most part, things are going very well. (It probably helps that I looked into Delphi once or twice, though I never got too far in.) However, I'm trying to achieve something, and I'm stuck. I'm sure it's because of my PdoxDOS outlook on things.
Basically put, the application I'm developing is tracking high school exchange students. One of the things I need to keep in each student's record is the hobbies and sports that student is interested in. (This is to help match a student to a potential host family -- being able to search for a student interested in a particular hobby is a huge help.)
The various hobbies and sports are kept in a table with two fields -- one is the interest itself, and the second is the category (Sport, Musical, or Other) that the interest belongs to. A table is used because at least once a year we come across an interest or hobby we've never heard of before. It's much easier to simply add a record to a table than it is to re-design a form, etc.
In PdoxDOS, I had a child table that contained two fields -- the StudentID and the Interest. It was a 1:M relationship, with multiple interest records for each student ID.
I populated that child table by scanning (a Paradox function that iterates through every record in a table) the interests into a Dynamic Array (an array with an alpha index whose size can grow and shrink as necessary) and presenting the choices to users performing data entry in a dialog box. The users simply selected the appropriate interests, and the selected interests were then entered into individual records in the child table.
I'm not married to the idea of a child table in A5. It could just as easily be a memo field in the student record, with each interest enumerated, separated by commas. That's simply a structure question. (Though the child table might still be the best approach for querying on multiple interest matches.)
Where I'm falling down is how to present the choices to the user, and how to get those choices into either the student record or a child table.
Any pointers (including one liners to look at such-and-such a function) would be greatly appreciated.
Basically put, the application I'm developing is tracking high school exchange students. One of the things I need to keep in each student's record is the hobbies and sports that student is interested in. (This is to help match a student to a potential host family -- being able to search for a student interested in a particular hobby is a huge help.)
The various hobbies and sports are kept in a table with two fields -- one is the interest itself, and the second is the category (Sport, Musical, or Other) that the interest belongs to. A table is used because at least once a year we come across an interest or hobby we've never heard of before. It's much easier to simply add a record to a table than it is to re-design a form, etc.
In PdoxDOS, I had a child table that contained two fields -- the StudentID and the Interest. It was a 1:M relationship, with multiple interest records for each student ID.
I populated that child table by scanning (a Paradox function that iterates through every record in a table) the interests into a Dynamic Array (an array with an alpha index whose size can grow and shrink as necessary) and presenting the choices to users performing data entry in a dialog box. The users simply selected the appropriate interests, and the selected interests were then entered into individual records in the child table.
I'm not married to the idea of a child table in A5. It could just as easily be a memo field in the student record, with each interest enumerated, separated by commas. That's simply a structure question. (Though the child table might still be the best approach for querying on multiple interest matches.)
Where I'm falling down is how to present the choices to the user, and how to get those choices into either the student record or a child table.
Any pointers (including one liners to look at such-and-such a function) would be greatly appreciated.
Comment