nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

MakeTableView in python script fails after Update to 10.3.1 on 64 bit OS

JessicaFraver1

Hi,

Since upgrading ArcGIS Desktop from 10.2.2 to 10.3.1, we receive a new error in our python scripts that use MakeTableView - arcpy.MakeTableView_management(sourcewrkspc + sourcedata, "in_memory\\" + layer, whereclause).

The script error is as follows:

ERROR 000358: Invalid expression

Failed to execute (MakeTableView).

Further tests revealed that the arcpy.MakeTableView does not work on tables with no OBJECTID. Registering the table with the database generates an OBJECTID and gets rid of the error, but this is not an option for some of our tables.

Has anyone experienced this problem with 10.3.1 and know why this error happens? Is there a fix besides creating a workaround to add an OBJECTID?

Thank you!

Find more posts tagged with

Accepted answers

All comments

se2539

I just want to say I'm glad I found this thread. Was having trouble with my script on my desktop machine running 10.3.1; kept getting a 000358 error even though I didn't even have an expression ... it was blank. Out of frustration I decided to upgrade to 10.5, ran the script without making a single change and it worked.

se2539

While this works, it kind of defeats the purpose of having all geoprocessing parts of a script run 'in memory' (which is what I'm trying to accomplish)

LeeAllen

Seems to be fixed in 10.4.1. This post was very helpful, I ended up skipping 10.3 and going to 10.4.1 because I have several scripts that broke at 10.3.

PhilLarkin1

This is fixed in 10.4. I tested against a non-sde table (no object ids). My situation is similar to Jessica Fraver's and have resorted to Scott Davis's solution in the past.

There are at least two bug reports that are possibly associated.

BUG-000088142: Executing the Make Table View tool fails, and return..

BUG-000090109: The Make Table View tool fails with "ERROR 000358: I..

Jean-ChristopheSAINTE

Hello.

I have the same issue with a model builder using MakeTableView that was running perfectly from 9.2 to 10.1. Now I'm using 10.3 and it doesn't work anymore. The same error code is returned (according to SQL statement that is however empty !). I tried several things to find where the error could be (remove strings with quotes inside fields values, apply a where clause to get all records 1=1, export table to text file and use this...). Finally the model builder works fine without any changes if the table used for MakeTableView contains less than 101 records... Is there a "max records parameter" somewhere that could have been changed or applied in the 10.3 version ?

Have a nice day !

ScottDavis

I was able to workaround this bug by copying the table to a temp GDB before calling MakeTableView.

Waan

Thanks Dan, I was actually wading through some of them when you replied. While there were some fixes to MakeTableView in 10.3 and 10.4, they seemed to deal with specific issues, e.g. when working on a .csv. I didn't see anything to indicate a broader fix.

I re-opened a ticket with Esri about this issue. For the sake of completeness in this thread, here's my piece of code that bombs ... this is a table and a feature class in a file geodatabase:

wellboretable = workspace + "tbl_wellbores"
wellbores = workspace + "wellbores"
arcpy.MakeTableView_management(wellboretable, "wellboretable_layer")
arcpy.AddJoin_management("wellboretable_layer", "UniqueId", wellbores, "UniqueId", "KEEP_ALL")
arcpy.SelectLayerByAttribute_management("wellboretable_layer", "NEW_SELECTION", "(\"tbl_wellbores.Deviation\" = '' OR \"tbl_wellbores.Deviation\" IS NULL) AND \"wellbores.Length_ft\" >= 3000")

Lest anyone thinks the syntax in the select statement is bad, I used GetCount_management, Exists, ListFields, and CopyRows_management to verify that data existed, the join worked, and the fields were typed accurately. I also tried using single and double quotes instead but still received an error. Interestingly, I noticed GetCount_management would return 0 after a bomb, so I used a CLEAR_SELECTION throughout my testing. To make this even simpler, I tried the following after the join:

arcpy.SelectLayerByAttribute_management("wellboretable_layer", "NEW_SELECTION", "\"tbl_wellbores.OBJECTID\" = 1")

... which still threw the same ERROR 000358. To be sure, I used a SearchCursor to verify that an OBJECTID of 1 exists in this table view. I emphasize that all of this code works fine in 10.1. I didn't spot anything in 10.3 (or 10.3.1) documentation that the SelectByAttribute syntax or SQL syntax had changed.

I'll see what Esri has to say.

DanPatterson_Retired

On my blog near the top, I have links to the change logs performed in arcmap, if you want to wade through and see if one is mentioned that involves maketableview, this would be the shortest path other than filing a bug error yourself. Have a look

The ...py... links

Waan

Hi Kathleen,

Have you found a workaround for this? Did Esri get back to you about a bug report? We are testing an upgrade from 10.1 to 10.3.1 and found a vital script is failing after a MakeTableView (error is actually thrown by a subsequent SelectLayerByAttribute).

Thanks,

-W

KathleenCrombez1

I found a few bugs had been reported that seemed relevant to this issue.

Both said the issue had been fixed in version 10.4

I just upgraded to 10.4 and am still having this error occur.

These scripts run fine in version 10.2.2

DanPatterson_Retired

If no one has reported it, there will be no error report. If one has been filed, then you could ask your tech support for a contact number.

some links

Error reporting for ArcGIS software—Help | ArcGIS for Desktop

then each version of arcmap contains a document like this, so since you are using an older than current release version, chec to see if the error had been reported and solved. If it isn't on the list, it probably wasn't reported...it is buried in a huge list.. or hasn't been fixed, or it isn't a software error but a user error or procedural difference of opinion. Here it is anyway\

http://downloads.esri.com/support/downloads/other_/104-IssuesAddressedList.pdf

KathleenCrombez1

This continues to be an issue for us.

We have several scripts that have been written over the years that we either have set to run on scheduled tasks or we run annually during different times of the year.

Most of these scripts now fail at version 10.3.1 due to this error.

ERROR 000358: Invalid expression

This error is occurring on both the MakeTableView and MakeFeatureLayer methods.

All of our tables and layers have OBJECTID fields.

I really hope that someone from ESRI can track the error down and fix it soon. We have already upgraded all our desktop machines to 10.3.1 and are hoping to upgrade our servers in a couple months. But this issue is going to leave us dead in the water if it isn't fixed.

AlisonGaiser1

Has anyone logged a call with Esri? If so, anyone have a bug number?

We are up and running by adding in the OBJECTID field in our materialized views so not sure what kind of call we would post to Esri Canada?

AnnStark2

Just wanted to chime in that we are having the same issue with MakeTableView not working in 10.3.1 environments but the same exact script running just fine in 10.2 environment (we store the scripts on a network drive so it is the same script in each instance that is run). We tried adding the OBJECTID to the table (in this case a SQL View), based on comments in this post, but that did not solve the problem for us.

Our python statement looks like this

arcpy.MakeTableView_management(UTILITY_BILLING_CUSTOMERS, Utility_Billing_Customers_View, "", "", "OBJECTID OBJECTID VISIBLE NONE;...<many fields here>")

in case that's of interest to anyone. No WHERE clause is used.

It sounds like a bug and hopefully will be addressed in 10.4.

KathleenCrombez1

Joshua Bixby,

It is strange, because I have other MakeTableView statements with a where clause that run before this one and they all run fine.

This is the line that throws the error in 10.3

Here is the error

Here are the field properties of the Summary_CondoPin table

One thing I did notice about the Summary_CondoPin table is the where clause returns zero records. So maybe that has something to do with the error.

But as I mentioned before, this line runs fine without error in 10.2

JoshuaBixby

Can you provide an example of a where clause that fails?

KathleenCrombez1

I have run into the same error using the arcpy.MakeTableView_management function on a feature class that HAS and OBJECTID field.

I am also using a where clause in the function.

The script runs perfectly in 10.2 but fails on this function in 10.3

JessicaFraver1

Hi Alison,

Unfortunately, we still don't understand what happened to make either the tables/views without an object ID, or the MakeTableVIew tool, behave differently with 10.3.1. We ended up adding a step in the script to search for the ObjectID field. If there is an ObjectID proceed with MakeTableView, if no ObjectID, CopyRows to in-memory. The remainder of the script is the same. This in not ideal for several reasons, but it works for us for now.

In response to Dan's reply:

"Did you try it somewhere else than in-memory? or perhaps without a whereclause to narrow down whether it is for some inputs, all, or a combination?"

We tried modifying output location and whereclause in different combinations, but nothing worked.

If you find another workaround, or potential cause of this error, can you please post it? I will do the same.

Thank you,

Jessica

AlisonGaiser1

Jessica,

We are experiencing the same issue here. We also cannot add an OBJECTID to the table we are accessing.

Did you find any other fixes or workarounds?

Thanks,

Alison

DanPatterson_Retired

Nothing indicated here Make Table View—Help | ArcGIS for Desktop

But the procedure is described here and MakeTableView is the route to do so... Fundamentals of ObjectID fields—Help | ArcGIS for Desktop and be sure to check the sublinks.

Did you try it somewhere else than in-memory? or perhaps without a whereclause to narrow down whether it is for some inputs, all, or a combination?

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.