IDEA
|
@DougMorgenthaler - any timeline on when this may be implemented? Thanks!
... View more
10-03-2022
11:18 AM
|
0
|
0
|
1384
|
POST
|
We've also noticed something similar with our PostgreSQL enterprise database and AGS 10.8.1. Does anyone know of any documentation on how the shared instance pool handles database connections? Is there any way to control how long AGS will keep an idle database connection open or any way to force those connections to be recycled?
... View more
04-09-2021
09:26 AM
|
1
|
1
|
819
|
POST
|
We're working with Esri (Canada) support on this... possibly an issue with Wine. Still no resolution for 10.7.1, but looks like the issue is fixed with 10.8.1 Python 3 runtime.
... View more
10-16-2020
09:29 AM
|
1
|
3
|
1251
|
POST
|
Hi Leon - did you ever get any support from Esri on this? I have also run into exactly the same issue. By sending the standard and error output from my cron job to a text file: * * * * * conda activate /home/arcgis/envs; python /home/arcgis/my_test.py >> /home/arcgis/cron_test.txt 2>&1 I was able to get this additional error message which seems to happen when the first call to arcpy is made: Fatal Python error: Py_Initialize: can't initialize sys standard streams OSError: [WinError 6] Invalid handle Current thread 0x0000024c (most recent call first):
... View more
08-27-2020
05:47 PM
|
0
|
0
|
1251
|
POST
|
The issue for us was that our CA certificate (.pfx file) didn't contain the complete certificate chain. Once we had created a new .pfx that included the root and intermediate certificates and installed that on AGS (along with installing the root and intermediate separately in AGS as well) we didn't have any more problems.
... View more
10-03-2019
12:11 PM
|
3
|
1
|
426
|
POST
|
Thanks for the suggestion Jason - unfortunately installing the certificate on the device made no difference and we still get the message "The server you are trying to connect to cannot be verified" when opening the map in Collector and none of the layers load. Seems to be an issue with the way ArcGIS Server (10.3.1 on Windows) is sending out the certificate (with an incomplete chain). The same certificate is used without any issues on one of our other (mail) servers.
... View more
12-19-2017
12:01 PM
|
0
|
5
|
1166
|
POST
|
We are experiencing the same issue - has there been any progress on this? I can confirm we are using Collector for Android v17.0.4 on a variety of devices. All our (ArcGIS Server) services are secured, and we don't get the authentication popup on any of our maps. Our server certificate is CA signed and shows as trusted in Chrome on the Android devices. Are there any workarounds?
... View more
12-08-2017
04:02 PM
|
0
|
7
|
1166
|
POST
|
We've been getting a generic "Sync Error" message when trying to sync edits to an archive enabled table that uses PG_GEOMETRY. If you ignore the error, the edits seem to make it back into the table successfully but Collector still shows there as being edits in the map to sync. Seems to only be a bug with archive enabled feature classes, as we don't get the same error with versioned data using PG_GEOMETRY (NIM102072 and NIM102073 I think). Does anyone at Esri know when this might be fixed? We'd really like to be able to use pg_geom but this issue with Collector is holding us back. We're using ArcGIS Server 10.3.1 on Windows and PostgreSQL 9.3 with PostGIS 2.1 on Linux. Thanks!
... View more
08-31-2017
12:19 PM
|
0
|
0
|
250
|
POST
|
I take it back - the datestyle setting was the issue It needed to be set on the database (or in postgres.conf) to 'ISO MDY' before enabling archiving on the feature class. If you make the change after the trigger function has already been created, the SQL DELETE returns successfully but the WHERE gdb_to_date = "12.31.9999 23:59:59.999" clause still fails to delete the feature out of the base table. With the datestyle set to MDY before archiving, the trigger function changes slightly to use "12.31.9999 23:59:59" (without the .999) and the SQL DELETE works.
... View more
01-05-2017
03:29 PM
|
0
|
0
|
643
|
POST
|
Thanks for the suggestion Chris, but it doesn't seem to make a difference as the datestyle that causes the problem - "12.31.9999 23:59:59.999" - is written in the trigger function created by SDE for an archive view. Seems odd that it should be written in this way when all other dates in the function are written as "9999-12-31 23:59:59".
... View more
01-04-2017
10:17 AM
|
0
|
0
|
643
|
POST
|
I get the following error when I try to delete from an archive enabled feature class view (DELETE FROM myschema.mytable_evw WHERE objectid = 3;): ERROR: date/time field value out of range: "12.31.9999 23:59:59.999" LINE 2: ... WHERE objectid = old.objectid AND gdb_to_date = '12.31.999... HINT: Perhaps you need a different "datestyle" setting. QUERY: UPDATE myschema.mytable SET gdb_to_date = current_timestamp(3) AT TIME ZONE 'UTC' WHERE objectid = old.objectid AND gdb_to_date = '12.31.9999 23:59:59.999' CONTEXT: PL/pgSQL function myschema.nvv_update_11() line 15 at SQL statement ********** Error ********** ERROR: date/time field value out of range: "12.31.9999 23:59:59.999" SQL state: 22008 Hint: Perhaps you need a different "datestyle" setting. Context: PL/pgSQL function myschema.nvv_update_11() line 15 at SQL statement Updating and inserting records to the view works, but not deleting. Is this deliberate, and if so, why? I'm using a 10.3.1 geodatabase in postgres 9.3.15 on linux. Thanks Simon
... View more
01-03-2017
02:47 PM
|
0
|
3
|
2013
|
POST
|
Hi, Is there any news on when the patch will be released for allowing archive-enabled related tables to be edited offline in Collector? Thanks!
... View more
06-29-2015
12:50 PM
|
0
|
0
|
2843
|
POST
|
Turns out this is a bug (NIM102734) which just applies to postgresql when timezone is UTC and data is archived (thanks Andy C at Esri Canada). Seems to be fixed (not reproducible) at 10.3 with postgresql 9.3.4.
... View more
03-03-2015
01:57 PM
|
0
|
0
|
390
|
POST
|
When editing an AGS feature service in an ArcGIS online web map, the editor tracking timestamps (created_date, last_edited_date) are being set incorrectly - their timestamp is being recorded as UTC +8 hrs (local time is UTC -08:00). Edit tracking is set to use UTC time, not database time, and the feature class has archiving enabled. If I edit the feature service through ArcMap, the correct timestamp is used. On other, non archived, feature services the edit tracking is recording the correct time (UTC). Does anyone know what might be causing this?
... View more
02-24-2015
01:48 PM
|
0
|
1
|
3231
|
Title | Kudos | Posted |
---|---|---|
1 | 04-09-2021 09:26 AM | |
1 | 10-16-2020 09:29 AM | |
3 | 10-03-2019 12:11 PM |
Online Status |
Offline
|
Date Last Visited |
01-25-2024
11:38 PM
|