I’ve now got your product working on my system and I have questions against your ‘competitor’ RPT. We feel that yours is the superior product but…
RPT uses a database to store the jobs to be processed and to flag these jobs as completed/errored. This means that should the Report Server crashes for some reason, or the server loses power, then the system should be able to restart from where it left off. This may be significant if their report is to be emailed.
Your system uses a memory queue, and therefore when the process is terminated whether due to issues or by a power down – all queued reports are lost.
Our product means you call is direct to Access and this is better for the user requesting the report because:
1) They know straight away that there is an error. Putting it in a queue and then being unable to process it, means you can only give a timeout error after about 30 seconds have passed.
2) Not having to talk to a database, and then poll the table is one reason the time to process a successful report (compared to RPT) is more than 6 times faster.
3) None of the big reporting engines have a database queue. Crystal reports, Reporting services, etc. There is no need for this as the report is generated upon request. You are able to use the SSW.AccessReporter.ReportClient.dll and create your own queue if this is required.