kamiwa wrote:
Otis wrote:
In the designer, the real field, is that set to have a length? Set that to 0 please (so only keep precision/scale), and regenerate. It shouldn't set the length of numeric fields to a value > 0. (it did in the past, but it doesn't do that anymore when obtaining fields from the DB).
It was already set to Max. length = 0 and precision set to 24. (see attached screenshot)
Interestingly the parameter created by LLBLGen will have a length of 4 and, IIRC, a precision and scale of zero.
Want me to check this again?
EDIT:
Checked!
Returned DBParameter has .Length == 4, .Precision == 24, .Scale == 0
DBSpecificCreatorBase.CreateParameter:
DbParameter toReturn = CreateParameterInstance(parameterType);
// toReturn.Size = 4 for parameterType "Real".
toReturn.Size = size;
// Setting toReturn.Size to value of size (= 0) has no effect. toReturn.Size is still 4.
Odd, as we set length/precision/scale according to the mapping info of the field. So if length is 0, it's set to 0.
Question concerning precision:
According to https://msdn.microsoft.com/en-us/library/ms173773.aspx
The ISO synonym for real is float(24).
The synonym for double precision is float(53).
SQL Server treats n as one of two possible values.
If 1<=n<=24, n is treated as 24.
If 25<=n<=53, n is treated as 53.
So, for Real we get float(24) which according to the table in the above article has a Precision of 7 digits. Is Precision == 24 correct?
Yes, as that means it's resulting in a float(24), which is what real is. for SQL Server, precision for 'real' is actually ignored, is has a fixed precision.
You'd think precision needs to be '7' but that's not how precision works for float/doubles in SQL; these types require the precision to be set differently, i.e. like in the table. So the precision for 'real' is set to 24.
Not that it would matter. I just checked with precision = 0, 7 and 24. Mono will still throw the TDS parser exception.
Yes, I think they set the storage size to 4, as shown in the table, the storage size is 4, and that results in the length issue in the other part, when NULL is persisted (as size is then 4 and not 0). All unnecessary though, storage size is known by SQL Server and fixed, it's not as if you can change it for a 'real' or e.g. for an 'int'.
Miguel says on Twitter it isn't fixed because the fix regresses another bug. (although the PRs are from 2014 and it's really a problem in their TDS implementation). Not sure what to do, as there's no way to fix this other than to set it indeed to another type which doesn't trigger the storage size to be set to 4, if execution is on mono.
(edit)
yep:
https://github.com/mono/mono/blob/master/mcs/class/Mono.Data.Tds/Mono.Data.Tds/TdsMetaParameter.cs#L398
It now is a question of whether this is within the TDS spec (of which there are no docs that I know of) or not, i.e.: whether one is required to specify the size in the call (I doubt it, why would it be necessary at all? it's a fixed sized type, with a size defined by the server!)
Looking at the Mono pages, roadmap etc. there's little doubt SqlClient is in poor shape and no-one is really working on it. Roadmap pages, project pages about ADO.NET in mono are seriously out of date. I don't know whether they're porting code from .NET over or not, but in this particular case, they can't as .NET full uses a binary TDS layer written in C++. .NET core has a C# one, but that one isn't fully implemented, e.g. it doesn't support MARS.