Problem Removing Join with 32 bit Python 2.7

[MichaelVolz]

To All Python Programmers:

I had a python script to update a feature class in a personal geodatabase using a join to a table view which works fine at 10.0 with Python 2.6.  I am now trying to run this script on a 64 bit Windows 2008 Server using the 32 bit version of python 2.7 since personal geodatabases are not accessible with 64 bit python.

I am crashing the script when removing a join with the following error message

"ERROR 000800: The value is not a member of  l ALIASES."

Has anyone ever encountered this error message and been able to resolve the issue?

Any help or hints in regard to this issue are greatly appreciated.  Thanks.

[SteveSalas]

I do not recall all of the details, but I know I had to update some Python scripts by leaving the join name parameter blank (which removes all joins) for them to function properly.  Sorry, I can't remember more of the specifics just now...

[ChrisSnyder]

in a personal geodatabase... 64 bit python

I assume you have the 64-bit background geoprocessing thing installed. If so, you must uninstall it if you want to use PGDB format. See "unsupported data types" in this help topic: http://resources.arcgis.com/en/help/main/10.1/index.html#//002100000040000000

[ChrisSnyder]

Woops - Sorry - reread your original post and I see you are already accounting for that (by using the 32-bit version)...

Not sure what's wrong.

[MichaelVolz]

I was able to resolve this issue myself using the technique that Steve described.  In my python v10.0 based version I entered a join name parameter in the Remove Join method.  This parameter was the cause of the error in v10.1.  I removed this parameter and the script ran successfully.

At this point I'm not sure how the script was able to run successfully at v10.0.


Steve:

If you have a script where you have multiple joins, then the Remove Join method will remove all the joins even if you might only want 1 of the joins removed.  As such if you still needed at least 1 of the other joins, you would need to add that join again.  Doesn't that workflow seem like a workaround to a bug where you are unable to remove individual joins?

[RhettZufelt]

I had a similar issue with joins that were set up on the data or mxd itself.

All the joins that I added with python, I was able to remove individually by name.

So, my workaround was to not have any initial joins, and create them all in the python script, then I can add/remove at will.

R_

[MichaelVolz]

Rhett:

When you created your joins in python, where did you assign the name to the join?  I did not give my joins a name in the python script, so I could see why python would not be able to remove the join as it has no idea what the actual join name is.

[RhettZufelt]

Sorry Michael, it seems I confused myself a bit.

It was with indexes that I had this issue and had to work around it.

For the joins, you just have to know what the name that was assigned to the join is, then it can be removed without error (just tested again in 10.1).

â? If the join table was a dBASE file named MyTable.dbf, the join name would be "MyTable"; so to remove it, specify "MyTable". 
â? If the join table was an INFO or Geodatabase Table named MyTable2, the Join Name would be "MyTable2"; so to remove it, specify "MyTable2". 
â? The join name will not reflect the name of the table view itself, but rather the source of the table view. Therefore, if a table view is named TableView1 and points at mytable.dbf, the name of the join will be "mytable". 

My joins are to table(s) in FGDB so something like:

summary = "\\\\mcflight01\\MCFlightData\\rzworking\\script_baks\\wc98116\\update\\data_4_temp_services.gdb\\summary"
wids_full_buffer2 = "\\\\mcflight01\\MCFlightData\\rzworking\\script_baks\\wc98116\\update\\temp.gdb\\wids_full_buffer"
wastebuffers3 = "\\\\mcflight01\\MCFlightData\\rzworking\\script_baks\\wc98116\\update\\temp.gdb\\wastebuffers3"


arcpy.MakeFeatureLayer_management(wids_full_buffer2, wids_buffer_Layer, "", "", "")

arcpy.AddJoin_management(wids_buffer_Layer, "SITECODE", summary, "SITE_CODE", "KEEP_COMMON")

arcpy.AddJoin_management(wids_buffer_Layer, "SITECODE", wastebuffers3, "wids_full_buffer_SITECODE", "KEEP_COMMON")

arcpy.RemoveJoin_management(wids_buffer_Layer, "summary")

arcpy.RemoveJoin_management(wids_buffer_Layer, "wastebuffers3")

I can use either or both of the removes to remove thier respective joins (need to specify layer and join name).


R_

[MichaelVolz]

In my original script I created a table view in a file geodatabase using a table extracted from SDE.  I stored the name of the view in a variable that I declared at the beginning of the script.  I then used the variable in the AddJoin_management statement to provide the name of the table to join to the feature class.  I used multiple permutations of the the table name (variable without quotes, variable with quotes, table view name without quotes, table view name with quotes), but they always failed.  The only way to get the RemoveJoin_management statement to execute properly was to leave the join_name parameter blank.

As such, I have no idea how to implement RemoveJoin_management by supplying the join_name parameter.

[RhettZufelt]

I can't seem to be able to make it work either.  Must be related to the table view, as if I join directly to a table, it works as in my previous post.

I did notice that if I copyRows to an in_memory table, then join to that it works as expected, just not with the table view.

R_