topic Re: sde_logfiles error in PostgreSQL in Data Management Questions

sde_logfiles error in PostgreSQL

dkav — Mon, 04 Nov 2013 17:19:41 GMT

Does anyone know why I am getting the following error in PostgreSQL for active ArcCatalog connections:

2013-11-04 11:10:49 PST ERROR relation "test.sde_logfiles" does not exist at character 174
2013-11-04 11:10:49 PST STATEMENT SELECT logfile_name, logfile_id, logfile_data_id, registration_id, flags, session_tag, column_name, logfile_data_db, logfile_data_owner, logfile_data_table FROM test.sde_logfiles WHERE flags%2 = 0

Occurs for users with and without schemas.

I am using ArcGIS 10.2 and PostgreSQL 9.2.

Re: sde_logfiles error in PostgreSQL

dkav — Mon, 04 Nov 2013 17:55:55 GMT

Here is a partial answer to my own question.

The missing tables are created, to quote ArcGIS Help, "in the schema of the connecting user the first time the user makes a selection that exceeds the selection threshold. For ArcGIS for Desktop, this threshold is 100 records."

So why does ArcCatlog try to do a Select when the tables have not been created (or if the user has no schema)?

Re: sde_logfiles error in PostgreSQL

VinceAngelo — Mon, 04 Nov 2013 19:08:13 GMT

How would ArcGIS determine if the table had been previously created without executing
a SELECT on it? The standard database API doesn't have a "table exists" function, it just
returns a NO_SUCH_TABLE on a SELECT. These log messages are not errors, just noise.

- V

Re: sde_logfiles error in PostgreSQL

dkav — Mon, 04 Nov 2013 22:07:38 GMT

One example (there are others) -
select exists(Select table_name
From information_schema.tables
Where Table_Name = 'sde_logfiles' and table_schema = 'test')

Some context - This is a new installation and we are trying to resolve issues that users are experiencing. Distinguishing between noise and valid errors is a step by step process. When you have over 70 connections and each producing this same error, it seems valid to wish for the noise not to be present. We are using the default log settings.

Thanks!