This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

JobEngine35.sdf Design Flaw?

Why is SolarWinds using a SQL Server Compact Edition file as part of its "enterprise-class" Orion job engine/APM scheduler? 

C:\Documents and Settings\All Users\Application Data\SolarWinds\JobEngine\Data\JobEngine35.sdf is limited in size to 4 GB by Microsoft (see http://en.wikipedia.org/wiki/SQL_Server_Compact).  SolarWinds lowers the maximum size still farther to 257 MB (I assume as part of the db connection string in the code), thus creating an inability to assign a large number of application monitors to a large number of nodes.  This kills the Job Scheduler Service (repeatedly) when we try to do this, and results in the following error on the Orion website:

The database file is larger than the configured maximum database size. This setting takes effect on the first concurrent database connection only. [ Required Max Database Size (in MB; 0 if unknown) = 257 ]

Why isn't the full version of SQL Server being utilized for this purpose, since Orion uses it anyway?  This is severely impacting our ability to implement this tool in our large environment.  We have multiple tickets open on various aspects of this issue, and cannot move forward until it is resolved.

If SolarWinds intends to continue using the SQL Server Compact Edition, can the job scheduling be extended to the pollers (i.e. poller-bound)?  That would at least spread out the load a little.