1

I'm having issues with some CAML deployed list instances. After deploying the lists, they do not appear in SharePoint Designer. Likewise, when attempting to connect to (almost all of) them, either a 500 internal server error or 404 not found response is returned to the browser.

This is happening when you simply test the (empty or populated) lists using /_vti_bin/listdata.svc/{listname}.

The contents of the list schemas seem pretty straightforward:

One Lookup -

<Field ID="{Guid}"
    Name="TheName"
    DisplayName="TheName"
    StaticName="TheName"
    Type="Lookup"
    List="Lists/TheParentList"
    ShowField="Title"
    Required="TRUE"
    Indexed="TRUE"
    RelationshipDeleteBehavior="Restrict"/>

Many Text fields (nothing too out of the ordinary), like -

<Field ID="{GUID}"
    Name="TheName"
    DisplayName="The Name"
    StaticName="TheName"
    Type="Text"/>

A single DateTime field -

<Field ID="{GUID}"
    Name="TheName"
    DisplayName="The Name"
    StaticName="TheName"
    Type="DateTime"
    StorageTZ="UTC"/>

And a single User field -

<Field ID="{GUID}"
    Name="TheName"
    DisplayName="The Name"
    StaticName="TheName"
    Type="User"
    List="UserInfo"
    UserSelectionMode="0"/>

Alright, so here's where things get weird. I can test ListData.svc before deployment and it works as expected. If I deploy the wsp containing the list schemas, this behavior begins to be observed, even though all of the lists load in the browser just fine, and all the forms work. If I then delete the Lookup, DateTime, and User field in one list AND DELETE ALL THE OTHER LISTS in an attempt to determine the source by process of elimination, I still encounter this problem. So to be clear, at this point there's nothing more than a single list with a bunch of text fields, and I still keep getting bad responses with ListData.svc.

In the ULS logs there's consistently an error thrown every time I try to hit the REST service:

System.Data.SqlClient.SqlException: Arithmetic overflow error converting expression to data type int.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.HasMoreRows()
at System.Data.SqlClient.SqlDataReader.ReadInternal(Boolean setTimeout)
at Microsoft.SharePoint.SPSqlClient.ExecuteQueryInternal(Boolean retryfordeadlock)
at Microsoft.SharePoint.SPSqlClient.ExecuteQuery(Boolean retryfordeadlock)

Alright, so what is it trying to cast as an int?

Does anyone have any insight into what this might be? I have been scouring the farthest corners of the Internet trying to figure this out.

In the meantime I'm going to keep "process of elimination"-ing it up.

2
1

And, I got it: The ListTemplate element's Type attribute value was causing the issue.

The documentation states:

Keep in mind that Microsoft Corporation products that are built on SharePoint Foundation, such as Microsoft SharePoint Server, can and do define additional list types. Also, Microsoft SharePoint Foundation farms where your solution is deployed may have custom list types created, for example, by adding a CAML ListTemplate Element (List Template) to a Feature or to the ONET.xml file of a custom site definition configuration. (Such custom list types should have ID values above 10000 to ensure that they do not conflict with numbers that will be used by Microsoft in future versions of SharePoint Foundation.) Since these list types are not have corresponding values in this enumeration, you should consider not using this enumeration as a parameter value in your custom methods. Consider, instead, using String or Int32 parameters that take the list type ID as string or integer.

Well, just be careful not to go too high above 10,000. My numbers were 8 digits, having a 6 digit prefix and then a numeric counter (still certainly lower than either C#'s Int32.MaxValue or SQL's int's upper range). I dropped them to slightly above 10,000 and the issue resolved itself. Ahh, SharePoint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.