SDE_compress_log - Where did it go?

[deleted-user-zpcJw1u0IXiO]

I maintain in SQL Server an ArcSDE geodatabase named "BC" that synchronizes twice weekly via Python script (attached) to a remote geodatabase named "BCWA". The script has been running successfully for several years, which I know because the script writes to a CSV file the pre- and post- compress state and lineage counts, and the length of time compress took to complete. I monitor the CSV in Excel.

I can see in Excel that there's no trouble on "BCWA", but the last time I could say the same for "BC" was February 26, when Excel shows it went from a state count of 67 before compress down to 15 afterward, and likewise from a lineage count of 163 to 51, and the compress task took just over 15 minutes.

Since that date, Excel shows every run of the Python script with a pre and post state count of 0, a blank lineage count, and a blank compress time. This made me think perhaps the compress task is being skipped, but when to troubleshoot I ran compress manually, it completed within 60 seconds and reported no error. The number of rows in SDE_states and SDE_state_lineages, however, did not change.

Today in SSMS I viewed the SDE_states and SDE_state_lineages tables in both "BC" and "BCWA", and noted that the record count of SDE_states in "BCWA" matches the end_state_count shown in SDE_compress_log, just as I expected. But on "BC", I could view SDE_states and SDE_state_lineages, but found there is no SDE_compress_log to compare it to! Ack!

Both "BC" and "BCWA" are 10.3.1 geodatabases, but Database Properties for "BCWA" says "database internals such as stored procedures can be upgraded." So the Upgrade Geodatabase button is enabled. Could it be that whenever it was that I clicked that button for "BC", one of the database internals upgraded caused the removal of table SDE_compress_log? I don't believe I pressed the button for "BC" after Feb 26, so this idea may be irrelevant.

Will someone please suggest what might be causing this problem and how I might fix it? I really need to get compress working again on the "BC" geodatabase.

Thanks,

Justin

[deleted-user-zpcJw1u0IXiO]

In case it helps, another thought has just came to mind: I upgraded to Desktop 10.4 on March 3, i.e. the day before the next scheduled run of the python script. Could this have impacted things? From my perspective it would explain nothing about why "BCWA" still compresses and not "BC".

[deleted-user-zpcJw1u0IXiO · Accepted solution]

Further to my "it would explain nothing", I discovered later the same day the source of my trouble. The "BC" geodatabase runs on SQL Server 2008. I learned that ArcGIS 10.4 drops support for that DBMS. "BCWA", by the way, runs on SQL Server 2012. On a colleague's machine running 10.3.1, the SDE_compress_log in "BC" is visible. Additionally, on that machine the 911 address table is visible, but on mine, it is not.

Short of upgrading the DBMS, the workaround is to install the SQL Server 2012 client on the DBMS machine.

[George_Thompson]

Here is a KB article that references that information for ArcGIS for Server 10.4 (would still be applicable for Desktop 10.4)

46427 - After upgrading to ArcGIS 10.4 for Server, existing services that use data in geodatabases i...

Here is the System Requirements for ArcGIS 10.4 and MS SQL Server: Microsoft SQL Server database requirements for ArcGIS 10.4—Help | ArcGIS for Desktop

Managing Data​ Enterprise GIS​