Latest Contributions by WilliamCraft

How about converting your newly-created CSV file from step 1 into a GDB table using the Copy Rows GP tool under Data Management?  For a CSV file input to this tool, the first row of the CSV file will be used as the field names for the output. Keep in mind that those field names cannot contain spaces or special characters.  Alternatively, you could generate an empty table with the field names and data types you care about and then add the rows from your CSV into the empty table using the Append GP tool. ... View more

The best way to get an answer to this would be to post your Shapefile to this forum thread inside a ZIP file.  In general, you'll need a Python script that will select record by attribute based on species value, then export a shape file based on the selected records, then convert the output shape file to a raster file.  This would be automated for each of the species.  What format are you expecting for your raster images (e.g., TIFF, GRID, JPG)?  Which version of the ArcGIS software are you using?  Which version of Python do you have installed? ... View more

We use Citrix for our overseas editors (about 100 people) using 9.3.1 SP2.  What version of the software are you using?  Can you be more specific about what you're trying to do?  I don't think there would be much in the way of running scheduled geoprocessing tasks on a Citrix server, assuming ArcGIS Desktop and Python are installed and the input data is accessible. ... View more

From my experience, the checkerboard (I've always called it chessboard :)) look and feel is related to incomplete or incorrectly-created overviews (through no fault of yours).  To get around this, I used the Define Overviews GP tool and checked the box for Force Overviews.  This option generates overviews for all extents, ignoring raster pyramids of the source data during the process.  Try this on a subset of your data that you know has checkerboard issues to verify, but hopefully you'll have good luck with this approach. Alternatively, there could be a difference in pixel depth among your various input source rasters.  Check the pixel depth (e.g., 1-bit, 8-bit, 16-bit, etc.) to see if you have a mixture.  I found this to be the case at one point in the past; I ended up forgoing the entire mosaic dataset approach and instead going with an unmanaged raster catalog stored in a file geodatabase.  You may need a mosaic dataset for your specific workflows, so this may be irrelevant to you.  If you don't, consider using an unmanaged raster catalog published as a map service (from an MXD not an MSD if using 10.0) as a workaround rather than a mosaic dataset as part of a map or image service. ... View more

What does Fiddler say when requesting the service? What type of data source are you using?  What version of ArcGIS (and, if applicable, ArcSDE) are you using?  What is your RDBMS version (if applicable)? ... View more

Weekends are pretty much mandatory as a DBA, whether a GIS DBA or not.  That being said, I don't see a need for this to occur every weekend unless there is some very special, specific need to do so.  We have what's called "Database Weekend" at my organization where we have block time (planned downtime) for our production databases in order to perform necessary maintenance that couldn't otherwise be done when users are connected.  Friday nights at close of business tend to be the least disruptive time to begin this type of work.  For us, this includes rebuilding geometric networks, compressing to state 0, making schema changes that require exclusive locks, server patching and rebooting, and a variety of other tasks.  The number of people needed for this type of work is dependent on the complexity and size of your environment as well as the amount of maintenance that you need to do.  Database weekend is once per month for us, and we publish the schedule in advance so users know that at 5 PM on Friday night we will be taking the databases down.  We send out an email to the user community a few days beforehand in order to remind them of this, and we send another email to them when the databases are available again for the users (this could be late Friday night, Saturday afternoon, or Sunday morning depending on the volume of work).  So, I think the answer to your question is "yes, you should plan to work weekends but probably not every weekend".  If you have some control over when maintenance is done and how it is structured, then I would suggest setting up a workflow with block time (e.g., planned downtime) like I've described above.  That way everyone knows what to expect.  Changes that require down time should wait until Database Weekend, unless there is an emergency of some sort.  Also, analyzing objects and rebuilding indexes can be done with users connected during regular business hours, although many will script this to run nightly or weekly.  I would also recommend a nightly automated reconcile and post (depending on your workflows and versioning structure) followed by a compress if your edit volume is what you say it is.  That should reduce the wait time for your block time compress when and if you need to go to state 0.  One additional thing for the moment... if you want to prevent users from accessing the database(s) while you are performing your QA/QC prior to reconciling and posting, there are many approaches that work for this, one of which includes temporarily locking non-essential database accounts.  I've had good luck with this approach because I can lock out regular users but not folks on the database team (i.e., administrators).  Of course, you'll want to script this if you have a lot of users. ... View more

In reviewing your code briefly, you might have the parcel and point layers in opposite places when issuing your select by location.  Here are the properties of the GP tool: SelectLayerByLocation_management (in_layer, {overlap_type}, {select_features}, {search_distance}, {selection_type}) If you're trying to select features from the parcels, then I believe parcels should be specified for the select_features parameter.  There may be other issues, but this was my observation when looking at it quickly. ... View more

This isn't surprising, actually.  Glad you got things working.  After the initial copy, you should be able to manage all of your data moving forward with the 10.2.1 client and your SQL Server native client on 'System A'. ... View more

Thanks.  Please mark the correct answer with the green check. ... View more

It might be a data type issue with that particular feature class whereby SQL Server 2012 doesn't like something from SQL Server 2005.  For the problematic feature class, perform an SDELAYER -O DESCRIBE_LONG in 9.3.1 SDE command line: sdelayer -o {describe | describe_long} [{-O <owner | -l <table,column>}]          [-i <service>] [-s <server_name>] [-D <database>]           -u <DB_User_name> [-p <DB_User_password>] [-q] Maybe do another describe_long on a feature class that you know copies fine to see what the difference could be.  Also, what does SQL Server 2005 say its backend data types are for the various columns in the problematic table? ... View more

One more thing, please provide the exact version of SQL Server you are using (Express 2008R2, Enterprise 2012, etc.).  Hopefully you are not using SQL Server 2005.  ArcGIS 10.2.1 supports versions of SQL Server 2008 and 2012 but does not support SQL Server 2005. ... View more

So it's just that one feature class causing issues; might be something with one or some of the records in that feature class.  Can you try loading the data using the method I described above for that one feature class?  In ArcCatalog, right click the 10.2.1 feature class and click Load, then pick your source 9.3.1 fature class and map the fields.  Usually, if there are issues with specific records, the Simple Data Loader will list the OBJECTIDs so you know what needs to get fixed. ... View more

Is your data stored as low precision?  You can check this by looking at its properties from ArcCatalog.  I would think that copying and pasting the data would automatically create the data at high precision in the 10.2.1 database, though.  What happens if you create an empty feature class in the 10.2.1 database with the same exact field structure as what's stored in 9.3.1 and then use the Simple Data Loader to import the records? ... View more