ServiceStack ORMLite 5.11.0 SQL Issues - Too Many Parameters - ormlite-servicestack

We are seeing an issue where with the ServiceStack ORMLite 5.11.0 version we are getting the below error related to reaching teh maximum of 2100 parameters.
Exception:
System.Data.SqlClient.SqlException (0x80131904):
The incoming request has too many parameters. The server supports a maximum of 2100 parameters. Reduce the number of parameters and resend the request.
We recently upgraded from ServiceStack ORMLite 4.0.46 version where we are using the same dataset and not seeing this issue, so seems like a change in logic on how ORMLite is handling the dataset now.
Is there anyone that has run into this similar issue and what was done to resolve the issue to get it working with the newer version of ServiceStack ORMLite?
SQL Generated from 4.0.46 version:
SELECT "POOL_VEH_UID", "POOL_UID", "UNIT_ID", "START_DT", "END_DT", "CRE_BY_ID", "CRE_TS", "UPD_BY_ID", "UPD_TS"
FROM "POOL_VEH"
WHERE (("UNIT_ID" In (1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,...2110) AND ("POOL_UID" = CAST('00000000-0000-0000-0000-000000000000' AS UNIQUEIDENTIFIER))) AND ("END_DT" is null));
SQL Generated from 5.11.0 version:
SELECT "POOL_VEH_UID", "POOL_UID", "UNIT_ID", "START_DT", "END_DT", "CRE_BY_ID", "CRE_TS", "UPD_BY_ID", "UPD_TS"
FROM "POOL_VEH"
WHERE (("UNIT_ID" In (#1,#2,#3,#4,#5,#6,#7,#8,#9,#10,#11,#12,#13,#14,#15,...#2110) AND ("POOL_UID" = CAST('00000000-0000-0000-0000-000000000000' AS UNIQUEIDENTIFIER))) AND ("END_DT" is null));

The issue is because OrmLite has switched to using parameterized values which your large IN() statement exceeds the maximum limit that SQL Server allows.
You can avoiding large parameterized values and revert to using a parameterless IN statement with a custom SQL fragment:
.Where($"UNIT_ID IN ({ids.SqlJoin()})");
If preferred you can also use typed Column and Table names.

Related

Invalid column definition error when using four part name to access Oracle DB as SQL Server linked server

I have setup a linked server in SQL Server 2008 R2 in order to access an Oracle 11g database. The MSDASQL provider is used to connect to the linked server through the Oracle Instant Client ODBC driver. The connection works well when using the OPENQUERY with the below syntax:
SELECT *
FROM OPENQUERY(LINKED_SERVER, 'SELECT * FROM SCHEMA.TABLE')
However, went I try to use a four part name using the below syntax:
SELECT *
FROM LINKED_SERVER..SCHEMA.TABLE
I receive the following error:
Msg 7318, Level 16, State 1, Line 1
The OLE DB provider "MSDASQL" for linked server "LINKED_SERVER" returned an invalid column definition for table ""SCHEMA"."TABLE"".
Does anyone have any insight on what my be causing the four part name query to fail while the OPENQUERY one works without any problems?
The correct path to follow is to use OPENQUERY function because your linked server is Oracle: the four name syntax will work fine for MSSQL servers, essentially because they understand T-SQL.
With very simple queries, a 4 part name can accidentally work but not often if you are in a real scenario. In your case, the SELECT * is returning all the columns, and in your case one of the column definition is not compatible with SQL Server. Try another table or try to select a single simple column (e.g. a CHAR or a NUMBER), maybe it will work without problem.
In any case, using distributed queries can be tricky sometime. Database itself does some optimizations before executing commands, so it is important for the database to know what it can do and what it can't. If the DB thinks the linked server is MSSQL, it will take some action that may not work with Oracle.
When using four part name syntax with a linked DB different from MSSQL, you will have other problems as well, for example using database builtin functions (i.e. to_date() Oracle function will not work because MSSQL would want to use its own convert() function, and so on).
So again, if the linked server is not a MSSQL, the right choice is to use OPENQUERY and passing it a query that use a syntax valid against the linked server SQL dialect.
If you use the OLEDB provider for Oracle you can query without using openquery

Trace the Cause for update of Sql Table

I have a table Product which have Quantity column, This table get updated thru .net application using Stored procedure based on flag variable. Now im having problem reported from user that even though the flag variable is not set table is getting updated with new values.
Now i need to isolated the cause for the issue.How will i check which update and through which application this table is getting modified. I have no idea about it.
What is the best approach to resolve this issue?
Assuming you are using SQL Server:
You can monitor calls to SQL Server using SQL Server Profiler. You can setup a filter to monitor queries affecting the Product table. The log will show what the query looked like, when the query was executed, the database user executing the query, the name of the application (if that is specified in the connection string) and a bunch of other things.

Issuing PRAGMA statement in AIR app

When I use the flash.data routines to issue a SQLite "PRAGMA encoding" statement, I get an error suggesting that this isn't supported:
'Error #3115: SQL Error.', details:'PRAGMA is not allowed in SQL.', operation:'execute', detailID:'2005
Is there a workaround?
In a word no. See for supported and unsupported features.
http://help.adobe.com/en_US/as3/dev/WSd47bd22bdd97276f1365b8c112629d7c47c-8000.html#WSd47bd22bdd97276f-5741a41a1262b2de46b-8000.
However on that page however you will see...
System table access is not available
The system tables including sqlite_master and other tables with the "sqlite_" prefix are not available in SQL statements. The runtime includes a schema API that provides an object-oriented way to access schema data. For more information see the SQLConnection.loadSchema() method.
For a more detailed help in using loadSchema have a look at,
http://gmarius.posterous.com/a-test-33
and consider using,
http://sqlitebrowser.sourceforge.net/ In fact

odp.net mixes up / caches clob column

I have an ASP.NET 4.0 application where I'm using NHibernate 3.0 with ODP.NET (newest version) to access a Oracle Express 10g database. All is working fine except the CLOB column is getting mixed up in my objects.
Example:
Http request /product/1/:
All returned columns values are OK.
Http request /product/2/:
All returned columns values are OK, except the CLOB column. The returned CLOB column is from the previous loaded object.
The problem disappears when disabling connection pooling.
But I'd like to use connection pooling and it doesn't feels right as a solution. Is this a bug in the ODP.NET or are I'm missing some built-in "feature"?
I had a similar problem and setting "Statement Cache Purge=true" in the connectionstring solved it. But I admit it's a very strange case because it occurs only with clob.
May you could try to set the metadata pooling attribute to false, when declaring ODP's connection string. See doc: Supported Connection String Attributes

Parameter count does not match Parameter Value count

We're getting a server error saying "Parameter count does not match Parameter Value count." Anyone have any idea what this could mean?
Our site's on ASP.NET Webforms running DotNetNuke as a CMS.
I've tried uploading an older version of the web.config file but it doesn't seem to have changed since the error came up. It wasn't in any of our recent module file uploads because I reuploaded the old files from this morning that we changed.
Could any changes in the database cause this or would it have to originate from an error in the code?
Thanks.
Some SQL query or stored procedure has more parameters specified then parameters' values received.
Something like this:
command.CommandText = "EXEC test #a";
command.Parameters.Add("#a", "a");
command.Parameters.Add("#b", "b");
i.e. look at the database scheme. Was it changed? Were stored procedures changed?
I've found that if you are using parameters that have default values, certain libraries can't handle.
For instance, we have an application that uses an older version of Microsoft Enterprise Library Data Access method that allows you to pass parameters as an array.
It fails if the amount of items in the array doesn't match exactly the number of parameters on the stored procedure, regardless if some are 'optional' or not.
In cases like this have to use straight ADO.NET and use the cmd.Parameters.AddWithValues("#parameterName", value)
syntax for the required stored procedure parameters. You will not have to add, when using this method, command parameters for the 'optional' stored procedure parameters.
I had the same problem and I found that it was picking the fields from a temporary cache which was being maintained by MySQLHelper.

Resources