These difficulties are due to the need for backwards compatibility and the new architecture. If you examine an SS2K5 (or SS2K8, for that matter) MSDB database, you will notice the original db_maint... tables that support the old SS2K maintenance plans and architecture.

You will also notice two sets of dts... type tables (dts... and dts...90). These are to support both the old SS2K and new SSIS packages.

Even in SS2K, the data between the db_maint tables and SQL Agent job tables were linked, but only parsed by the Database Maintenance Wizard.

The same is true for SS2K5 (only parsed by the Wizard); however, the database maintenance tasks are now defined through SSIS packages and stored in BLOBs within the dts...90 tables.

So, the jobs are not scanned (or reconciled) until the Database Maintenance Wizard parses them out.

You must keep in mind that the BIDS interface is NOT the DBMW; however, BIDS can connect to a SQL Server repository to extract dts table packages, and then edit them through that interface. BIDS can then "Save As" a new dts table package (The Repository) on the same SQL Server instance, another instance on the same host, or a remote instance, just like the DTS Designer version 8.0 (SS2K). But, because BIDS is NOT DBMW, the jobs are not reconciled until opened by the later interface once BIDS has created the new package.

Hope this help clarify some of the mechanisms the SQL Server tools are employing.

Keep in mind that prior to SP2 (or was it SP1), there was no DBMW interface and all maintenance plans had to be administrated through SSIS and BIDS. So, the situation is improving. Take note that this appears to be the design direction, to elminate the DBMW and force adoption of SSIS entirely (maybe...)

Sincerely,

Anthony Thomas