Thanks for compiling all your issues up like this, Chris. Have discussed with our team, and our replies are below: 1. We diagnosed on Friday that the FeedFetcher application was not working due to the fact that we had created a “System” ODBC DSN (which is correct according to your documentation). The FeedFetcher began working correctly once we created a “User” ODBC DSN. Our technical team does not want to use a “User” defined ODBC DSN simply due to the fact that the data source is associated with a user and the Windows Service must also run under this same user. If the password of the user account changes or the user is removed from the system, the FeedFetcher will stop working. This is a huge risk for us and the “System” ODBC DSN is ideal and cuts that risk out of our implementation. Can you please advice on how we can get the FeedFetcher working correctly with a System DSN. XTS: Of the scores of SQL Server installs we've done, this is the first time we've run into this problem. We think it's likely some kind of systems-administration-level issue you have on your server(s) in terms of how permissions are doled out to "SYSTEM" DSNs. We're not Windows SysAdmin experts, but our hunch is that if you were to open up all system permissions wide (some kind of Windows equivalent to "chmod -R 777 /") then the System DSN would work just as well as your User DSN. Now obviously, you wouldn't want to run your servers like this. But it would prove that the problem lies not in our technology but in how the security settings on your servers are set up. One common approach is to indeed open permissions wide, see that the software works, and then little by little re-clamp-up the security settings, until it breaks again. With the knowledge gained, you'l be able to make custom modifications that retain the level of System security you seek. Given that FeedFetcher is working as a User DSN, I don't think there's anything else XML Team can do to analyze the security and permissions settings on your servers any better than you could. 2. From my understanding of how the FeedFetcher works, it retrieves files from XmlTeam, processes them and then inserts them into the database. The FeedFetcher also creates many log files. I need to know how much disk space (on average) the FeedFetcher’s files will take up over the span of a month (or week). FFD writes its logs to the logs\ directory, as you've seen. It pseudo-rotates the files, in that files get written to a logfile named for the date, and also get written to current-log.txt, which is alwasy kept small by the system. So you're welcome to zip up and/or delete and/or archive off any logfiles older than a week or month or year or whatever your preference. As far as the space taken up by FeedFetcherDeluxe\archive and by the SportsDB database, that is dependent upon how much content you're pulling. Since games are going on now, you can just measure that database today and again in a week, and extrapolate from there. FFD does no auto-deletions of old data, since we don't know what you want to keep. We can provide advice, for example, if you'd like guidance in how to clear out the mid-game scoring update files from your system during the off-season. 3. I need some help setting up the FeedFetcher to run in PUSH mode. No problem. Just give us your IP Address and Port in an XTOTS ticket, and we'll set up a Push Transmitter for that target. 4. Can someone please explain what I’m supposed to do with the “Fixture Keys” tab-delimited file? And how often this is updated? Will I have to update this file periodically whenever XmlTeam releases a new version of this file. The tab-delimited file is for your reference, and can help you understand the inventory of data. Also (and probably more) helpful is our Content Showcase at . If you choose to use our sportsml2html XSLT tools, then as we continue to add more support for fixtures, you may want to keep up with the new builds, which would entail pulling down updates of XSLT resource files. Major updates are publicized via our Client Blog. 5. In regards to the Team Keys sql script, how often is this file updated and will I have to update this file periodically whenever XmlTeam releases a new version. FFD 4.0 does not need this file, like FFD 3.9 used to. Instead, we have SportsML "League Directory" files. Currently, you have to download these manually when there are changes you want. In the future, we'll just be sending them over the feed. Shouldn't affect the NHL until the next League Realignment, of course. 6. It was recommended to us by XmlTeam to install the FeedFetcher directly on a SqlServer. As I had mentioned before this will introduce a security hole into our production systems due to the fact that we will have to open port ‘80’ on the server. Currently the port is closed and should never be opened. The reason given to us by XmlTeam is that the application can experience performance issues during times of heavy load. We are going against this recommendation and will be installing the FeedFetcher on our application/web server so that we do not introduce the aforementioned security hole into our production systems. Monitoring of the FeedFetcher application will be setup and if the application does experience performance issues then we would like XmlTeam to help us resolve these and its unacceptable for us to install the FeedFetcher on directly on our SQL Server. Likely you'll be able to "keep up with the feed" by having FFD on a separate server. Just try it out and you'll see pretty instantly (so long as games are going on). My guess is that previous clients who had a problem with this had some non-optimal networking set up among the computers. In terms of you having to "open Port 80" -- not quite sure what you mean. Yes, FFD *pulls* data down from XML Team's Port 80, but you don't have to have it open on your end. If you want us to PUSH data to your FFD, then of course you need to allow http-put requests to some port of yours. We recommend Port 8083, but it can be any port you choose, and you can of course implement IP screening on that, so that you're getting the data only from trusted XML Team push servers. Hope this helps. Please open individual (issue-specific) XTOTS tickets to follow up on any of the above. Regards, Alan.