# Storing FileSets in Database & Comparing Them

**URL:** https://www.finalbuilder.com/forums/t/storing-filesets-in-database-comparing-them/1491
**Category:** Discussion
**Created:** [May 29, 2010, 1:39am UTC](https://www.finalbuilder.com/forums/t/storing-filesets-in-database-comparing-them/1491 "2010-05-29T01:39:08Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![jonrobertson](https://www.finalbuilder.com/forums/letter_avatar_proxy/v4/letter/j/d2c977/32.png) [@jonrobertson](https://www.finalbuilder.com/forums/u/jonrobertson)
#### Post date: [May 29, 2010, 1:39am UTC](https://www.finalbuilder.com/forums/t/storing-filesets-in-database-comparing-them/1491/1 "2010-05-29T01:39:08Z")

</div>

I have a script that builds our redistributable packages.&nbsp; Currently, the script reads a text file containing filespecs for the package, builds a File Set containing files that are newer than the package date and, if any are found, rebuilds the package.

The problem is that files are not always promoted into a release shortly have they are built.&nbsp; So a file may have a date/time that is before the package date, but the version in the package is still an earlier version.

So I want start writing the package build history, including package contents, to a database.&nbsp; When the script runs to rebuild the packages, it'll compare the current file set date/times against the date/times stored in the database for the last package.

Has anyone stored File Sets & compared them in a similar way?&nbsp; I've thought of two approaches:

1. Build File Set & ADO Dataset Iterator, walk the ADO Dataset and compare it against the File Set.&nbsp; I don't like this idea very much, which is why I spent time thinking of another (and writing this post).
2. Build File Set and immediately populate it into a new "working" table.&nbsp; Then write SQL to compare the two tables and locate any mismatches.&nbsp; If any mismatches are found, the "working" table will be promoted to the "current package" table and the package will be rebuilt.

Any thoughts on these idea or alternative suggestions?

Thanks!&nbsp;
