Mercury

That's just it. It isn't simple. Believe me, I do understand that a simple 1:M relationship can be exported neatly from the Child table. Okay, I'll play along. From your example, we need multiple entries of Alpha and Bravo in the Parent table, with of course, other pertinent fields and a suitable primary key. Something like... [color:purple]Serial# ParentID: 1 Name: Alpha OtherField: Frog Serial# ParentID: 2 Name: Bravo OtherField: Horse Serial# ParentID: 1 Name: Alpha OtherField: Eel Serial# ParentID: 2 Name: Bravo OtherField: Dog Serial# ParentID: 1 Name: Alpha OtherField: Cat Then the required export is... [color:blue]Serial#,Alpha,Frog,101 Serial#,Alpha,Frog,102 Serial#,Alpha,Frog,103 Serial#,Alpha,Eel,101 Serial#,Alpha,Eel,102 Serial#,Alpha,Eel,103 Serial#,Alpha,Cat,101 Serial#,Alpha,Cat,102 Serial#,Alpha,Cat,103 Serial#,Bravo,Horse,104 Serial#,Bravo,Horse,105 Serial#,Bravo,Dog,104 Serial#,Bravo,Dog,105 As there are repeated ParentIDs in the Parent table, exporting from the Child table doesn't generate the results needed.

The concept of generating the records from the child relation is right, but where this example (and I assume the original poster's query) is different is that we are working with groups of people and displaying the groups works beautifully from the child. In this example (see attached image), the core Timetable table is populated with class IDs, the teacher ID etc. By using a StudentID portal you can see the teacher and all the students in the class at any point of time (Day,TimeSlot) and where they are (Room ID). Although I can neatly see and manipulate classes of students in this way, the data needs to be exported to a different system where each student's data for each Day and Timeslot in that day is to be a separate Tab delimited record. For example, students 1234 and 9876 are in the same class and move from Room5 to Lab2, to Room8, to Room5... [color:blue]Day,TimeSlot,StudentID,RoomID,TeacherID 1,1,1234,R5,T1234 1,2,1234,Lab2,T4321 1,3,1234,R8,T4444 1,4,1234,R5,T1234 ... 1,1,9876,R5,T1234 1,2,9876,Lab2,T4321 1,3,9876,R8,T4444 1,4,9876,R5,T1234 Exporting from the Timetable table generates a single record containing all the data, but subsequent Tab-delimited records exclude the common context fields. There's the rub. Trying to export from the Student table doesn't work as it is a 1:M relationship. Of course, the database design can be changed to focus on individuals rather than groups of individuals and then the export is simple. This, however, makes the manipulation of groups (Classes for me) less elegant. http://s254.photobucket.com/albums/hh112/MercuryAlbums/?action=view&current=Relationships.jpg

I've struggled with this, too. The only way I've managed to accomplish the export is to create an "export" table and populate it with a script. 1) Create a Temp window that holds the Export layout. 2) Revert to the original window and start a Loop to work through each record. Use variables to copy the data required in these records. 3) Within the Loop, create another Loop that flips from one Portal row to another (Goto Next Portal Row) and copy the data you want from the Portal row into a variable. 4) Before moving from one portal row to the next, Select the Export window, create a record and use the Set Field command to populate the new record with the data you have stored in the variables. 5) Select the original window and move onto the next Portal row. 6) Once the Portal Loop finishes... 7) Move to the next record so that the Portal loop starts all over again. Once the Export layout has been populated, you can then execute the standard export routine to get the data out. OK, I've been a bit brief in my summary. Hope you understand. (I guarantee that it works, as I've scripted a solution for myself.)

Seasons greetings to everyone. I need to create an in-house blog for the students at my school to use for the beginning of February. The overriding instruction is that the web-based solution is to be hosted on our Intranet using our FM8 server, so using any of the various free external blogs is not an option. I've written the hosted FMPro solution, but now I need to webify my solution. I've struggled with XSLT and sought help here in other posts and I'm now wondering if I'm on the right track. i) Is XSLT the way to go? Should I turf this and aim for PHP? (Note that although I have many years of programming experience, that I'm a novice at both.) ii) Is there a cheap, preferably a FMPro, solution that can be purchased? Any other advice will be gratefully accepted.

Thank you, Martin. You've actually given me much more that I wanted. I just needed this, I think... <?xslt-cwp-query -script=AuthenticateMe? > Is this right?

I'm just starting to write XSLT and I can't seem to be able to call a FM script from the XSLT code. Can someone give me an example of how to use the xslt query, please? Say the FM script is called AuthenticateMe and the script steps all have full rights... With thanks

I had a similar problem with bound applications that would work on one PC but not on another. I found the solution to be Internet Explorer; in fact and more accurately, the lack of IE. On Win9x machines, IE4 must be installed for the runtime applications to work. Of course, later versions of IE also serve the purpose. This little gem of information is tucked away on page 4-2 of the FMP Developer manual.

Regarding the restart for Unlimited, you can create a parent FMP database that automatically opens the database hosted on the server. The theory works this way: 1. Open the parent database on machine startup. 2. The parent database has a startup script that opens the Hosted file. 3. The parent database closes itself. These are the scripts I use: *Pause/Resume Script["0.00.03"] ... pause for 3 seconds (For edit access) *Open["Targetfile.FP5(*)"] ... Open the target file on the server. *Close["ParentFile.FP5"] ... Close the parent file. When scripting the OpenFile command, make sure that you use the HOSTS buttons to locate the server hosted file. Also make sure that you have at least a few seconds pause set first up, otherwise you'll never be able to get back into the parent file to edit it!