|
POST
|
The *EXACT* version of Oracle goes out to five places (11.a.b.c.d). Given the extreme age of ArcGIS 10.1, it is extremely risky to not have installed at least Service Pack 1. There are dozens of patches on top of SP1, and they ALL should be applied before reporting uncommon behavior. - V
... View more
11-17-2017
09:25 AM
|
2
|
4
|
2029
|
|
POST
|
ArcGIS 10.1 is rather old. Have you applied the SP1 service pack and a score or more of patches? What exact version of Oracle are you using? Is it listed as supported by 10.1sp1? Back when it was current, I used 10.1sp1 to load ten and hundreds of millions of features at one time (680m being the most). I must admit it's easier to do so now at 10.5.1, but there's no obvious reason why you should be having this issue. I suspect it's going to come down to a bizarre IT issue, like a router or firewall limiting traffic, or an antivirus app freaking out in some way. - V
... View more
11-17-2017
07:16 AM
|
0
|
6
|
2029
|
|
BLOG
|
I had a project where I needed to publish data at a service provider location, with the publishing to be done by a novice Desktop user. My solution was to make a Python toolbox to simplify the data import and ArcGIS Server service publishing steps, and then I just went ahead and made the export and cleanup steps tools in that same toolbox as well. This was looking like a great solution until network issues at the end-user site caused the data import step to take seven hours (instead of the usual 20 minutes). Since this was an Amazon solution, the utility could have been run on a VM from inside the mission, but there were issues accessing the license server from the VM, and from there, well, let's just say it didn't work out. Since my ArcGIS Server node was actually on a Linux box, I didn't have the option of running a graphical utility like a toolbox tool, but the code didn't really need graphical access (just a working ArcPy, a path to the source file geodatabase, and an enterprise connection file (.sde)). I could have ported the app to a command-line utility, then invoked the command-line from the toolbox UI, but this additional development would take time and, as I recently discovered, it wasn't strictly necessary, because Python toolbox ( .pyt ) files can be invoked from Python! For example, lets say we have this trivial toolbox: import arcpy
class Toolbox(object):
def __init__(self):
"""Define the toolbox (the name of the toolbox is the name of the
.pyt file)."""
self.label = "Toolbox"
self.alias = ""
# List of tool classes associated with this toolbox
self.tools = [BlogTool]
class BlogTool(object):
def __init__(self):
"""Define the tool (tool name is the name of the class)."""
self.label = "BlogTool"
self.description = "Trivial tool example"
self.canRunInBackground = False
def getParameterInfo(self):
"""Define parameter definitions"""
param0 = arcpy.Parameter(
displayName="Options",
name="in_options",
datatype="GPString",
parameterType="Required",
direction="Input")
return [param0]
def isLicensed(self):
"""Set whether tool is licensed to execute."""
return True
def updateParameters(self, parameters):
"""Modify the values and properties of parameters before internal
validation is performed. This method is called whenever a parameter
has been changed."""
return
def updateMessages(self, parameters):
"""Modify the messages created by internal validation for each tool
parameter. This method is called after internal validation."""
return
def execute(self, parameters, messages):
# invoke helper
return doExecute(parameters[0].valueAsText,messages)
def doExecute(param1,messages):
messages.addMessage("Tool: Executing with parameter '{:s}'".format(param1))
return None
It works like you'd expect: Now, if you run it from the command line, despite it not having a .py suffix, you get no error, but it doesn't do anything either: Ahh, but if you tweak the toolbox to add an extra two lines of code to the end: if (__name__ == '__main__'):
arcpy.AddMessage("Whoo, hoo! Command-line enabled!") Then you can use the toolbox from a console: "Still, they're not connected, and what about messaging?" you ask. Well, this is pretty cool: You can fake the messages parameter in the tool's execute method with a stub class that does everything you need messages to do, and you can grab parameters from the sys.argv array, which makes for a command-line capable toolbox: if (__name__ == '__main__'):
arcpy.AddMessage("Whoo, hoo! Command-line enabled!")
class msgStub:
def addMessage(self,text):
arcpy.AddMessage(text)
def addErrorMessage(self,text):
arcpy.AddErrorMessage(text)
def addWarningMessage(self,text):
arcpy.AddWarningMessage(text)
import sys
doExecute(str(sys.argv[1]),msgStub())
Obviously, you'd want to do the sort of validation/verification for arguments that Desktop provides before invoking the helper with parameters, but that is, as they say, "A small matter of coding." - V
... View more
11-15-2017
11:26 AM
|
4
|
2
|
2229
|
|
POST
|
No, that's an m4 macro constant in an include file (.h) within the source tree. Even if Esri still shipped the 'C' API, changing it in your install would have no effect on the Esri binaries (except where doing so corrupted structures, in which case it would have an effect -- bizarre segmentation violations and pointer alignment exceptions in your code). - V
... View more
11-14-2017
11:00 AM
|
1
|
0
|
7773
|
|
POST
|
Please use an image format to share screen captures on GeoNet. Word documents are a potential malware vector, and therefore much less likely to be downloaded/opened. The beta license agreement usually stresses the use of a beta forum for questions and issues. - V
... View more
11-06-2017
12:34 PM
|
1
|
1
|
2451
|
|
POST
|
I think you meant PG 9.6.x is not supported by Esri for enterprise geodatabases, yet. It still might be possible to access a non-geodatabase instance of 9.6 with PostGIS 2.2 (though I haven't tried). You won't be using SDE.ST_Geometry with PG 9.6 until at least ArcGIS 10.6, since extension DLLs are locked to a specific PG release (9.3.x, 9.4.x,...), and 9.6 is not supported. - V
... View more
11-01-2017
06:59 AM
|
1
|
1
|
1881
|
|
POST
|
1Mb is probably too small, and will likely result in fragmentation if there is any other activity on that device. Try using fixed 100Mb or 200Mb segments (this will also likely improve insert performance). - V
... View more
10-26-2017
07:06 AM
|
2
|
0
|
2813
|
|
POST
|
It may not be as bad as you make it out to be. Obviously, implementing in PostgreSQL from scratch would be better, but if you need a PG instance anyway, using a materialized view that casts the MySQL data into real data tables with PostGIS geometry would be the best option, and should only take a day or two to implement. With that investment of time, you'd get a far more robust implementation than foreign data wrappers would achieve. Given the presence of 64-bit integers, you have other issues with Desktop implementation that would need to be addressed as well. Generally speaking, GIS integration is easiest if it's tackled first, as part of initial design, rather than as an afterthought. I know it wasn't your plan to do it that way, but I have to say I've seen a number of failed projects that were doomed through "deal with that GIS stuff later" design, so any time you have tables with longitude and latitude columns exposed in the bid phase, it would help to make sure you know what sort of GIS integration will be required before submission, just so you aren't burned again. Good luck. - V
... View more
10-23-2017
02:06 PM
|
0
|
0
|
1468
|
|
POST
|
Latitude and longitude are defined as VARCHAR; if they're degrees they should be NUMERIC. I'm not sure where you're going with "company_id int ai pk", since this is non-standard SQL (and fails in PostgreSQL). The only way this is going to work is if you create real tables in PostgreSQL, and "replicate" from the bridged table simulations to the real tables (once you've done it with tables you can try through materialized views). Your sample code should include each of the datatypes used in your customer database (ArcGIS won't even look at tables with a 64-bit integer), and you should have a geometry type column (named shape or geom or point), which is defined with the correct SRID (4326), because rendering through virtual geometry columns simulated from text coordinate values will yield evil performance. - V
... View more
10-23-2017
12:59 PM
|
0
|
2
|
1468
|
|
POST
|
Most of my projects are under NDA, but I've never had difficulty constructing a representative code sample that captures the spirit of the task without exposing forbidden details. Strip the CREATE TABLE down to just the geometry and serial columns, manually insert one feature (with whole number coordinate values), then try to access it. If that fails, you have your representative sample. If it doesn't, you have something to compare against, adding one column with a new datatype at a time until failure. - V
... View more
10-23-2017
11:43 AM
|
0
|
4
|
1468
|
|
POST
|
I'm sorry, but I won't do private consultations in violation of the spirit of open exchange here in GeoNet. I suggest you create similar SQL that exhibits the same behavior, and post that instead. The other alternative, of contracting with Esri for my time, would likely be prohibitively expensive (in dollars and time). - V
... View more
10-23-2017
10:55 AM
|
0
|
6
|
1468
|
|
POST
|
Now, the quirk in my environment might be that there are NO enterprise servers anywhere, this is strictly an ArcMap only environment No, that's not it. I've used dozens of different "non-gdb" PG databases on different servers without difficulty. You'd need to share your table creation SQL. You could be violating table naming rules, or column naming rules, or user naming rules, or any of other "plain vanilla SQL" restrictions (no spaces, no upper case, no leading numeric characters,... -- basically, if it requires a double-quote, it's not going to work), but it's not possible to tell without your code. - V
... View more
10-23-2017
10:15 AM
|
0
|
8
|
2398
|
|
POST
|
I have actual tables in a PostgreSQL database using PostGIS, not a wrapper, emulating that function. I also conform to ownership requirements (ArcGIS doesn't permit tables to be owned by groups), and GRANT my connection user the minimum access required (SELECT, in my case), with a different user and schema for table creation. The details of your replication implementation need to be reviewed, since there's a dozen different possible ways to achieve "replication", and not all of them will behave the same with an ArcGIS client. - V
... View more
10-23-2017
09:38 AM
|
0
|
10
|
2398
|
|
POST
|
So replicating 3 tables from MySQL into PostgreSQL to display via ArcMap will never work. No, that's not correct. Since the 10.4.0 release, PostgreSQL is special in that you can access PostGIS tables read/write without an enterprise geodatabase license. I do this all the time at client sites. Sure, you don't get full geodatabase functionality, but you can create feature classes in a PostgreSQL database via Desktop (Standard or higher) or Python (ArcPy), and you can insert to tables created via SQL with ArcPy cursors. The key is having a simple database design and utilizing the serial datatype to allocate rowid columns, to preserve 32-bit integer identifiers in the tables for Query Layer access. - V
... View more
10-23-2017
09:06 AM
|
0
|
12
|
2398
|
|
POST
|
It's really difficult to predict the difference in storage between RDBMS implementations. That said, I haven't noticed huge differences (except with respect to the RDBMS binary catalog overhead -- Oracle is a *huge* install). Note that porting an SDO_GEOMETRY-storage geodatabase to Geometry-storage would produce different characteristics than an SDE.ST_GEOMETRY source (due to compression in the SDE.ST_GEOMETRY implementation). - V
... View more
10-19-2017
02:27 PM
|
1
|
1
|
2813
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 2 weeks ago | |
| 2 | 06-08-2026 09:13 PM | |
| 1 | 05-29-2026 12:51 PM | |
| 1 | 06-01-2026 06:03 PM | |
| 2 | 05-29-2026 08:31 AM |