Here is a question that has puzzled me for many a year but i have never thought of posting as i just thought it is too annoying to tackle.

I like most break my data down into the smallest possible parts.. this is great for most kinds of report ... but ... the CV is as everyone knows a complex animal.

I want to create a database driven CV.

So I have several databases...

Education

Employment

Press

Publications

Events

Referees

Now i need these all on one sheet ... oh and they all have different layout formats ... and every time i print it it changes...

So do i have to create a CV database with multiple overlated layouts and import the data from each of these every time i print or is there a better way?

Anyone got any ideas...

Okay, I'll bite. What's a "CV"?

Curriculum Vitae Resume...

Never heard of it. Maybe you can explain the challenges you're having with it. It would help to see a data model, and maybe a mock-up of what the form should look like.

Hi Ender,

I think we are having contextual issues here.

I am English (although based in NY at the mo)

A CV is what you take to an employer when applying for a job (that printed bit of paper that lets someone you have never met before judge if your employable)

Its sometimes called a "Resume" in the US i think.

Its just a tricky thing in terms of data modelling.

Well, I think most people would just use a word processor to put their resume together. Or are you tracking resumes of a lot of other people?

Anyway, I thought you already had the tables for the different sections set up. Are they not yet related? I guess I still don't see what the trouble is.

I guess I still don't see what the trouble is.

It is a layout problem. At first sight it seems possible to create the document as simple list, but every chapter has a different structure and format.

-jens

On the button...

Its just that the basic principles do not apply as you can only have the body from one table and each "chapter" has a limitless number of entries and they are all from different tables.

You can not have multiple pages on a cv as it is not really acceptable.

Ender is correct in his assuption that i need to do this for many people (artists and designers). There agencies input this kind of data and see no reason why printing a cv would be a promlem

but... Its a real problem...

I thought if using the new "List" function and formatting everything in one field to send to print but this is a problem when it comes to Tabbed data as positioning a multi line block of text next to a date on the first line can not be achieved using this method.

Edited October 28, 200619 yr by Guest

I think it is hopeless to try to solve the problem inside filemaker with your multiple table model.

A list can only be formed from one table which keeps all the entries of the cv. The different chapters should not be different tables but an entry in a text field.

The tricky part will be the output field for all those different entries. I don't dare to say that it will be possible, but it is worth a try ...

-jens

Yes, this my current predicament.

The only reliable way i can se of doing it is creating the cv records when they are printed or called on.

This is the only way i can see of keeping the data in sync with the data entered in the other tables.

The only other way i can see of doing it to make it quicker is to do it with ids so that if data is edited it is reflected on the cv records and then the list of ids can be checked against the cv records to see if there are new or deleted entries.

actually now i come to think of it if i add a checkbox saying (include on cv) with a script attached to create or delete the entry from the cv the user would be none the wiser. The checkbox could simply check for the existance of its id in the cv database.

Then if the user deletes an entry from the cv database it simply unchecks the checkbox and leaves the original data alone.

hmmm

Suppose this is the best i can ask for and the best the user can ask for to.

Thanks guys.

Stuart

I take it you're tried to get this to work with a Form View layout using portals? Though portals don't behave well across page boundaries, they usually work on single-page forms.

yes unfortunately things need to shift up based on the content so portals will not do it in this situation.

(if you could only make a portal row change size based on content)

What exactly is the problem with portals sliding up?

Hi comment,

I have never been able to make the rows of a portal slide.

Maybe im doing something wrong?

Although i think you may mean making the whole portal slide up rather than the contents of the individual rows (which would be required in this case). Hope you can prove me wrong as this would be amazing.

PS, Comment... used a Cartesian relationship in the file attached just for the hell of it }:|

sliding_portal.fp7.zip

Edited October 30, 200619 yr by Guest

OK, I see what you mean. I don't know of a good solution, just some possible workarounds:

1. Import into a union table;

2. Compile the report into a single field;

3. Export via XML.

Hi Comment,

Thanks for the list of options...

I think the Union Table is maybe the best option.

But i would love to dabble with XML although i have never been able to get a good handle on XML Formatting.

I suppose i could use the list function to add it all into one field and use html tables and export the field as an html file to the desktop.

Edited October 30, 200619 yr by Guest

XML is not easy (probably the understatement of the year), but it can do some amazing stuff.

I am not sure what advantage HTML tables have here. You can compile the portals into a field (or even better, several fields - one field per portal), and use tabs to align the data.

I mentioned HTML Tables as it is a good way of getting around the problems with tabs and data spilling over to a second line: eg:

..... = tabbed

Without HTML Table:

1992

14 Jan - 14 Feb.....Exhibition Name, Exhibition Venue,

Other Artists, Catalogue

With HTML Table

1992

14 Jan - 14 Feb.....Exhibition Name, Exhibition Venue,

..............................Other Artists, Catalogue

Edited October 30, 200619 yr by Guest

Hmm. I don't think I've seen that problem in your file. Perhaps repeating calculation fields using GetNthRecord() (one field per column per portal) would be most suited here.

I'm jumping in here at the end, and I haven't even looked at the sample files, so I probably should just lay low, but...

What if you were to create an intermediary table that serves only as a bridge table?

This table would have a foreign key ID field, a Type field, and a calculated Content field that pulled in data from your various "real" tables. Create relationships from Bridge::fkID to the ID field in each real table.

The calculated field in Bridge would use a Case statement to select the ultimate real table data to use:

Content:

Case(

Type="Job"; JobTable::FullText;

Type="Educ"; EducTable::FullText;

...

)

Create a FullText field in each real table that concatenates the appropriate fields for that type.

Create a Value List of the types in the order you want them in your CV, and then use the value list order to sort the records.

I'm not certain, but this might yield workable results. It may be slow. Moreover, I don't even know how you'd build a user interface for this animal.

David