compile 'com.google.zxing:core:3.2.0'
compile 'com.journeyapps:zxing-android-embedded:3.0.2@aar'
答案 0 :(得分：1)
此处的问题可能是您在FILEGROUP_NAME()定义的SELECT子句中调用CursorIndex的地方。根据{{3}}，传递给filegroup_id的{{1}}参数的类型为FILEGROUP_NAME()。我希望您在smallint中有一条或多条记录，其sys.indexes值大于32,767（可以存储在data_space_id变量中的最大值）。
您可以通过运行来检查：
smallint这将返回有此问题的所有索引。我可以看到两种修复查询的方法：
SELECT SCHEMA_NAME(t.schema_id) [schema_name] ,
t.name AS TableName,
ix.name AS IndexName,
ix.data_space_id
FROM sys.tables t
INNER JOIN sys.indexes ix ON t.object_id = ix.object_id
WHERE ix.type > 0
AND ix.is_primary_key = 0
AND ix.is_unique_constraint = 0
AND t.is_ms_shipped = 0
AND ix.data_space_id > 32767
ORDER BY SCHEMA_NAME(t.schema_id),
t.name,
ix.name
来电中的FILEGROUP_NAME()来电 - 它看起来不像以后用于任何事情，所以不需要它被包括在内。FETCH子句，以排除WHERE值大于32767的任何索引。请注意，此方法将意味着某些索引不包含在游标中，但这些只会无论如何都是导致它失败的那些。至于为什么SQL Server允许data_space_id中的值大于32767而sys.indexes.data_space_id需要一个smallint参数，我不知道 - 也许其他人可以启发我们这个？