I would like to be able to accomodate up to 50 diferent teams and have the form print out to a multi-page PDF. I have all the player data in one database and the team data is in another. I can certainly create some multi-line variables for the player stats without too much trouble. My big issues is how to get repeating blocks for the different teams. A Matrix comes to mind but printing over multiple pages doesn’t seem to be an option. I also tried Data Tiles, but they want to utilize database fields instead of multi-line variables. Any help here is much appreciated.
It seems like this might be an application for summary records, summary headers and tiles (plus data tiles). But since we don’t know much about your underlying data, it’s hard to say for sure.
Or, since you seem to have a fixed number of player spots per team, perhaps a matrix on a data tile. Each data tile would print one team, the matrix would print the individual players for that team.
The first decision you need to make is whether you are going to print from the player database (in which case the summary record approach is needed) or from the team database (one record per team, with a matrix).
As far as I know FileMaker doesn’t have the same concept of summary records, so you might want to study that before making your decision. Here’s a help page on printing summary records.
The data in both Teams and Players is stored in dataarrays. I’m thinking it might be easiest to make a new database and populate it with multi-line variables for each of the player stat items. That could easily be set up with a data tile. I could also add to that database the pertinent team information and put that in the same data tile. Does that approach seem reasonable?
Data arrays are a great secondary tool for certain specialized programming. But to use them as your primary method of data storage seems like swimming upstream to me. In fact, let me make sure we are talking about the same thing – by “dataarrays”, do you mean this?
If you do, then I would very much suggest putting the data in the data sheet. This application doesn’t seem like it should have any multi-line data – every item is a small cell.
Where do the player stats come from? Is there a database of individual plays that is aggregated into the stats? And/or a database of games?
Yes that is what I meant by data array.
I have 4 databases that work together. They are named Control, Players, Teams and Scoresheets.
Control is used for generating Permanent Variables at the start of the season and for opening up the other databases on launch.
The Players database holds personal information on all of the players (required by national organizations) along with the season’s stats for each player.
The Teams database holds a Roster of players and a few stats for each team for the entire season
The weekly data is entered into the Scoresheets database where it is processed and then stored in the Teams and the Players databases. There are 35 games in each scoresheet and currently 13 scoresheets per week. The Scoresheet database is working very well after many hours of learning, programming and screaming.
I guess the main reason for using an array for the stats is to have ready access to each week’s stats for both players and teams.
This is turning into a much more complicated question than originally stated. I’m about to leave for WWDC, and can’t really devote much more time to this, perhaps someone else will pitch in.
A data array is pretty similar to a database with one field. But the data array is invisible and can’t be edited, grouped, printed, etc. Panorama puts many more tools at your disposal for working with databases rather than data arrays. It sounds to me like you should seriously consider creating a 5th database and using that instead of a data array.
The reasoning behind using arrays to hold the stats is that I need access to every week’s worth of stats for every player. Currently that is 28 weeks times 193 players.
I suppose I could do one database for each player and have one record for each week of play in there, but that would be 193 separate databases. Or I could do one database for each week of play and have one record for each player. That would only be 28 databases. Either way it gets very unwieldy, very quickly. The way I have it is one database for players which holds all of the personal info for them along with an array to hold the stats for the year. That array has 588 pieces of info in it. I thought that it might be too cumbersome to have 588 fields for each player.
Definitely DO NOT make a database with 588 fields! Not only would it be very cumbersome, it would have performance issues. The Data Sheet gets slow when going over about 100 fields.
I would suggest a database with 588 records, or some multiple thereof. You can use lookup( or superlookup( to access the specific data you need.
