Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

byte[] / Image SQL type with CE fails with byte arrays > 8000 characters #213

Open
davidfordaus opened this issue Nov 29, 2014 · 4 comments

Comments

@davidfordaus
Copy link

Related to this issue I believe:https://connect.microsoft.com/sqlserver/feedback/details/311412/sqlceparameter-limits-dbtype-binary-to-8000-characters-ssce3-5

In short: it looks as though Dapper needs to explicitly set the parameter type when binding parameters:

SqlCeParameter paramBlob = cmd.Parameters.Add("blob", SqlDbType.NText);

Any thoughts would be welcomed.

@mgravell
Copy link
Member

Yes, basically; same problem. It vexes me that MS don't "get" this.
On 29 Nov 2014 08:09, "davidfordaus" [email protected] wrote:

Related to this issue I believe:
https://connect.microsoft.com/sqlserver/feedback/details/311412/sqlceparameter-limits-dbtype-binary-to-8000-characters-ssce3-5

In short: it looks as though Dapper needs to explicitly set the parameter
type when binding parameters:

SqlCeParameter paramBlob = cmd.Parameters.Add("blob", SqlDbType.NText);

Any thoughts would be welcomed.


Reply to this email directly or view it on GitHub
#213.

@davidfordaus
Copy link
Author

Is there a simple fix for this ? (eg an interface to implement, subclass to
create, etc) - or is there no simple fix and I need to either place a hack
(at this stage I have exactly one table with one column of this type) into
recompiled Dapper code or switch (meh) to EF or similar? I'm happy with
Dapper thus far, apart from this and a few other more minor issues. Cheers

  • and thanks for the response.

On 29 November 2014 at 18:25, Marc Gravell [email protected] wrote:

Yes, basically; same problem. It vexes me that MS don't "get" this.
On 29 Nov 2014 08:09, "davidfordaus" [email protected] wrote:

Related to this issue I believe:

https://connect.microsoft.com/sqlserver/feedback/details/311412/sqlceparameter-limits-dbtype-binary-to-8000-characters-ssce3-5

In short: it looks as though Dapper needs to explicitly set the
parameter
type when binding parameters:

SqlCeParameter paramBlob = cmd.Parameters.Add("blob", SqlDbType.NText);

Any thoughts would be welcomed.


Reply to this email directly or view it on GitHub
#213.


Reply to this email directly or view it on GitHub
#213 (comment)
.

Best regards

David Ford
0421 659 552

@mgravell
Copy link
Member

It is a tricky one. Dapper tries to avoid specific client hacks, but we
have added such before - just usually not quite as specific.
On 29 Nov 2014 14:05, "davidfordaus" [email protected] wrote:

Is there a simple fix for this ? (eg an interface to implement, subclass
to
create, etc) - or is there no simple fix and I need to either place a hack
(at this stage I have exactly one table with one column of this type) into
recompiled Dapper code or switch (meh) to EF or similar? I'm happy with
Dapper thus far, apart from this and a few other more minor issues. Cheers

  • and thanks for the response.

On 29 November 2014 at 18:25, Marc Gravell [email protected]
wrote:

Yes, basically; same problem. It vexes me that MS don't "get" this.
On 29 Nov 2014 08:09, "davidfordaus" [email protected] wrote:

Related to this issue I believe:

https://connect.microsoft.com/sqlserver/feedback/details/311412/sqlceparameter-limits-dbtype-binary-to-8000-characters-ssce3-5

In short: it looks as though Dapper needs to explicitly set the
parameter
type when binding parameters:

SqlCeParameter paramBlob = cmd.Parameters.Add("blob",
SqlDbType.NText);

Any thoughts would be welcomed.


Reply to this email directly or view it on GitHub
#213.


Reply to this email directly or view it on GitHub
<
https://github.com/StackExchange/dapper-dot-net/issues/213#issuecomment-64945248>

.

Best regards

David Ford
0421 659 552


Reply to this email directly or view it on GitHub
#213 (comment)
.

@davidfordaus
Copy link
Author

Unfortunately there are times where specific accommodations need to be made
to adapt to the idiosyncrasies of the underlying target environment. This
is one of those. It can't be avoided in order to have Dapper work properly
for Image column types, and clearly the test cases miss this. It can
probably be handled in one of a variety of approaches:

  • An public API - Observer / Adaptor / Decorator style that allows an
    external end-developer person to create a class to "observe", view and
    modify the query just before its issued. SQL CE would use this to fix the
    Image problem. This could be specified either on a per-call basis (meh),
    or a static Dapper.Settings call.
  • An hidden version of the above but specifically around decorating a
    call. A SQL CE implementation would implement the fix.

I also believe that the Dapper docs on the front page should mention the
lack of Image support for SQL CE. I tested with a small string.GetBytes and
decided on Dapper based on the fact that it all worked. I didn't notice the
8k limit until yesterday. Some quick notes around limitations would have
helped to make more accurate decisions between EF, Dapper et al, as I now
need to download and patch Dapper myself to fix the bug.

On 30 November 2014 at 06:32, Marc Gravell [email protected] wrote:

It is a tricky one. Dapper tries to avoid specific client hacks, but we
have added such before - just usually not quite as specific.
On 29 Nov 2014 14:05, "davidfordaus" [email protected] wrote:

Is there a simple fix for this ? (eg an interface to implement, subclass
to
create, etc) - or is there no simple fix and I need to either place a
hack
(at this stage I have exactly one table with one column of this type)
into
recompiled Dapper code or switch (meh) to EF or similar? I'm happy with
Dapper thus far, apart from this and a few other more minor issues.
Cheers

  • and thanks for the response.

On 29 November 2014 at 18:25, Marc Gravell [email protected]
wrote:

Yes, basically; same problem. It vexes me that MS don't "get" this.
On 29 Nov 2014 08:09, "davidfordaus" [email protected]
wrote:

Related to this issue I believe:

https://connect.microsoft.com/sqlserver/feedback/details/311412/sqlceparameter-limits-dbtype-binary-to-8000-characters-ssce3-5

In short: it looks as though Dapper needs to explicitly set the
parameter
type when binding parameters:

SqlCeParameter paramBlob = cmd.Parameters.Add("blob",
SqlDbType.NText);

Any thoughts would be welcomed.


Reply to this email directly or view it on GitHub
#213.


Reply to this email directly or view it on GitHub
<

https://github.com/StackExchange/dapper-dot-net/issues/213#issuecomment-64945248>

.

Best regards

David Ford
0421 659 552


Reply to this email directly or view it on GitHub
<
https://github.com/StackExchange/dapper-dot-net/issues/213#issuecomment-64952840>

.


Reply to this email directly or view it on GitHub
#213 (comment)
.

Best regards

David Ford
0421 659 552

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants