10 proofs of each version from large data file.

[draco66]

I have a large job that we do a couple times a week.

 

There are 5 different postcard versions within the job and which one is printed for a given customer is based on a data field.

 

Before we actually compose the job and mail each batch we are required to provide 10 proofs of each version to the customer for approval.

 

I have been creating a set of proof data manually by finding 10 of each in the supplied data and copying and pasting them into my proof data. Then compose the proofs.

 

My question is.....Would there be a way to simply use the supplied data and have FP compose 10 of version one, 10 of version two and so on until it has 10 of each version completed? I realize this could take a while to compose as it looks through the data for records to compose. But I can launch this when I leave for the day and the proofs would be done in the morning. Would save creating the proof data file by hand. I know it doesn't take that long for only five different versions but we have other jobs in the works that will have as many as 100 versions all of which will need a set number of proofs each time. I am also trying to make this easy for someone else to produce if I am on vacation.

 

Thank you.

[GreggRusson]

If I understand you correctly, you have a database with some kind of segment/version field and want a quick way to create a proof file with n records from each segment/version. Use whatever SQL database RDBMS you want (such as MS Access) and write a corralated sub-query. It's basically a query within a query, eg, self joining a table to itself and returns the Top n records you specify for each version. Here's a link to get you going:

 

http://allenbrowne.com/subquery-01.html

 

Take a look at the 'TOP n records per group' example

 

Gregg

[step]

Does it matter if they're in order or not? If not, you could do something like this:

JavaScript Globals

versions = {};

OnRecordStart

var isProof = true;             // false to compose job normally
var version = Field("version"); // Field that indicates version
if (isProof) {
 if (!versions[version])
   versions[version] = 0;
 FusionPro.Composition.composeThisRecord = ++versions[version] <= 10;
}

The code creates a global 'versions' object and at the start of each record, it counts how many times each version has been composed. If a specific version has been composed more than 10 times, FP won't compose the record.

 

If you need grouped by version, you'd probably have to link to your data as an external data file and sort the versions up front.

[draco66]

Thank you for your suggestions. I will look into both of these options and see what will work best for us.

 

Thank you again for the quick replies.

 

Bob M.

[dreimer]

That is great Step, thanks for that. I would usually create a separate signoff data file but this allows me to skip that process.

[step]

That is great Step, thanks for that. I would usually create a separate signoff data file but this allows me to skip that process.

 

Awesome! Glad it helps

[GreggRusson]

draco66,

 

I've attached a Access db with 1 data table and an example of a simple select correlated sub-query to get 10 samples from each segment/sort grouping in the data table. Double click on the data table... a little over 36k records with 4 sort groups (A,B,C & E) and 3 fields, rec_id, sort & name. Now, right click and select the design view icon. Next select SQL view. Notice you have an inner & outer query which both reference the same table, hence the AS aliases. The inner query and outer query work together. The inner one runs first, selecting the TOP n (in this case 10) rec_id's needed by the outer query for each segment/sort group. I have just the basics for criteria, but you could easily add additional requirements, like the zip must be 10 characters and/or the country needs to be US etc... you could also add sorting specs as well if you like.

 

Another idea would be turning it into an Update query so you could post back to the database and flag the records selected for tracking purposes. In any event, for ~36k records, process time for me running on a Intel I7 box was just under 3 seconds!

 

Hope this helps,

 

Gregg

CorrelatedSubQueryExample.zip