Should the value in the database of a passed string value be stored as-is even is its parameter length is set to a larger value?

[ramonsmits]

When setting the length to a fixed value on a parameters for an UPDATE query and you pass a value that is less than that size what should be the outcome?

I see that if the previous value is longer than the new value that the value in the database has trailing data from the previous value:

old value: 11111
new value 222
value in database after UPDATE with parameter length set to 4000: 22211

Is that expected or is this a bug in the SQL Client? It feels as if a string buffer might be incorrectly reused and not "reset".

For now I'm not setting the parameter length for INSERT/UPDATE to fixed values and only do this for SELECT.

I can't find documentation on the behavior but it feels like a bug.

[ramonsmits]

What is missing in this question to get a response?

[ErikEJ]

A runnable repro?

[JRahnama]

@ramonsmits if you can come up with a repro that produces the issue constantly, please open a new issue at issue section.

[ramonsmits]

After trying to make a small reproduction and not being able to continued analyzing the code base that was failing.

The problem was caused by a ArraySegment<char> which was pooled thus re-used. The code assumed that the underlying char[] has the length of the data that was written to it but in fact it was larger.

Just by coincidence, the 'right' (prior) buffer was re-used for the update which resulted in the remaining of the previous value to still be visible.

With the profiler, I could see the prior value to be sent to SQL. Not only did it show the prior value but the full buffer (4096 characters).

Too bad I didn't spot that earlier....

In short, providing a string or array that is shorter than the Size property will behave correctly.

Unfortunately, SqlClient does not have proper support for Slice or Span so that a subset of the internal buffer can be passed to SqlClient instead of the whole internal char array buffer.