Hello everyone,
.Lyr files take too long to display in ArcCatalog 10.4 where datasource is an SDE SQL database.
Any ideas of how we can optimize that?
What is the time difference if you get the data directly from the SDE SQL database instead of via the lyr file?
Hi Michael,
Symbology. We have an AddIn to load dynamically several layers in a mxd using .lyr files.
This solution works very well in SDE Oracle, but in SDE SQL .lyr files are very slow.
So you have the same data in an Oracle SDE database as the SQL SDE database and you can bring in the same data with the same symbology much quicker from Oracle than from SQL?
Perhaps the below patch was created for this issue you are seeing:
https://support.esri.com/en/Products/Desktop/arcgis-desktop/arcmap/10-4-1#downloads?id=7422
I do not use SQL for storing enterprise data, but at 10.5.1 my organization did need to apply a Critical Patch for the Oracle SDE database to work properly.
Yes, that is exactly the environment we have. And also we are migrating from Oracle to SQL.
Thanks
Where the layer files regenerated, or newly created, for SQL Server or was the data source just updated?
Are both systems (Oracle and SQL Server) live during the migration, or have you already shutdown Oracle?
Hello again,
Question: Where the layer files regenerated, or newly created, for SQL Server or was the data source just updated?
.lyr files were created in ArcGIS 10.2 with SDE Oracle. All .lyr files were copied in a new folder, and datasource updated with ArcGIS 10.4. to point to SDESQL.
We are currently migrating in a development environment. Both systems are live by the moment.
How about bringing the symbolized data into ArcMap using the Oracle lyr files. Then in ArcMap resource the data to SQL Server. Then create brand new lyr files. This should remove any corruption you might get from using the existing lyr files. Rename existing Oracle lyr files as a backup so your Add-In can work with the SQL Server based lyr files.
My organization has run into issues resourcing older layer files to newer EGDBs. As Michael suggests, it is worth trying to create new 10.4 layer files sourced directly to SQL Server (not resourced in existing layer).
Michael, Joshua,
Sure, we are goimg to test Michael's solution.
We already changed the SDE datasource from one SQL instance to another and got better performance.
Jose:
I was just expanding on Joshua's observation about changing datasources instead of creating lyr files from scratch. I know in the upgrade from 10.3.1 to 10.5.1 for my org we had to rebuild certain objects from scratch as they either crashed completely or performed very poorly in 10.5.1 unless created brand new. I guess the lesson there for ESRI software is to rebuild objects at some frequency (maybe every 2-3 years especially if going through an upgrade) to keep objects working at peak performance.
These are the tests we did:
- created a new .lyr file in ArcMap 10.4 and save it as .lyr file pointing to SDE SQL 10.4. Same result, slow
- created a file geodatabase and copied to a feature dataset with layers used by the .lyr files. and point .lyr file to layer in FGDB. It runs fast, as it was running in SDE Oracle.
Conclusion: .lyr files that point to SDE SQL databases are slower than these same .lyr files pointing to SDE Oracle or FGDB.
Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
