Seems this bugs has been reported in 2014 and been extensively discussed. https://bugzilla.xamarin.com/show_bug.cgi?id=16892 Fixed: No! Status: New ( = untouched)

Well, I have no idea what to do, except cursing on the 'devs' that call themselves mono maintainers. We don't have a separate mono build, so I can't introduce hacks just for mono.

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).

Cursing is probably the best we can do. If you do it loud enough, it at least will make you feel better.

In the mean time I ran into another mono bug:

When inserting many records in a row (either one by one or in a collection) and the sum of the size of the insert parameter’s values exceed a certain limit (unspecified yet, limit still needs to be worked out) mono will quit the Insert process with a Mono.Data.Tds.Protocol.TdsInternalException: Server closed the connection.

This problem got reported in 2008 and is still existing. Proof: http://mono.1490590.n4.nabble.com/Mono-Data-Tds-Protocol-TdsInternalException-Server-closed-the-connection-td1502338.html

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.

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?

Not that it would matter. I just checked with precision = 0, 7 and 24. Mono will still throw the TDS parser exception.

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?

Yes please. The length shouldn't be 4. If the length is 0 in the mapping info, it's not set when the parameter is created. It might be they create their own bug by setting it to a size when the value is set... not sure.

See above! Race condition!

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.

Otis wrote:

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.

Yep. With the current state of the SqlClient, Mono is definitely not fit for use in production when it comes to using a Sql Server database.

Otis wrote:

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.

Probably it's best to wait for .NET Core. With the pre-release of Sql Server vNext, which does run on LINUX (https://www.microsoft.com/en-us/sql-server/sql-server-vnext-including-Linux), I'm sure that MS will come up with some solution for .NET to fully support their product on cross platform.

Otis wrote:

Well, I have no idea what to do, except cursing on the 'devs' that call themselves mono maintainers. We don't have a separate mono build, so I can't introduce hacks just for mono.

If you still wanted to provide a workaround for this mono bug and avoid a separate build for mono, you still could use my dirty hack. Instead of using a compiler switch you could use mono runtime detection ( http://stackoverflow.com/questions/721161/how-to-detect-which-net-runtime-is-being-used-ms-vs-mono ) and make the type change dependent on the runtime being used. To minimize performance impact, you could use a static isMono field in SqlServerSpecificCreator.

But who am I to make coding suggestions to you? You sure know better than me what should go into the LLBLGen code base and what not.

I can easily understand if you decide to not do anything at all. Hacking around this issue, would be just one more workaround for another mono bug.

It still wouldn't make using Mono with a Sql Server datasource fit for production. Even if you used LLBLGen.

Hmm. Their plan is to use .net core's implementation: https://twitter.com/migueldeicaza/status/813414704978808833

But when, it's unclear. Also he says the bug requires fixing, but when/how is unclear. There's no-one actively maintaining this code, so it's basically up for grabs, but who'll merge the PR is uncertain. Also, fixing it when the code will be replaced is also not going to make it a high-priority issue.

When you mentioned, that "Miguel said on Twitter ...", I was curious, what you two had to say and already checked your twitter account :-)

But thanks for keeping me updated anyway.

yeah, I have the feeling when netstandard20 arrives, mono will be effectively dead

FULL ACK

So what is your opinion on LLBLGen.Core these days?

Well, the runtime has been ported to netstandard1.6, templates are left. We hope to have something running by the end of January. Things cut are (for now) Binary serialization, datatable/set related functionality (including retrieval procs) and dependency injection, although the last one can be implemented in some way.

Hooray!

If you want a Beta Tester, you've got my mail address!

I'd like to port my developements from mono to .net core, using LLBLGen Runtime. Therefore, if you like to have an other beta tester. ;-)

Please see this post: http://www.llblgen.com/tinyforum/GotoMessage.aspx?MessageID=137171&ThreadID=23740

So it will be released, but for netstandard20 which has a timeframe of 'May 2017'. We'll have a beta out before that.

Things REALLY are in the move these days. see: http://www.llblgen.com/TinyForum/GotoMessage.aspx?MessageID=139004&ThreadID=23740

Thought you'd all be interested to know that the mono bug from the beginning of this post (http://www.llblgen.com/tinyforum/GotoMessage.aspx?MessageID=136028&ThreadID=23650) which I reported about more than a year ago to the mono maintainers (https://bugzilla.xamarin.com/show_bug.cgi?id=43795) finally got picked up. Classification of the bug has been changed as follows: Hardware: PC => Mac Component: Sys.Data.SqlClient => System.Data

Guess it won't take long now till they start fixing it.

Understand, why I can't await to stop coding against mono fw and start using .NET Core 2.0?

LOL, you might perhaps even get a patch before Christmas! fingers crossed

OTOH:

I've been following your struggle with MS toolage and corefx on twitter (following somebody on twitter still feels to me like stalking and is not something I do normally, I hate all this social media crap) and I just read what you posted on the .NET Core thread here on the forum.

I slowly get the feeling I should stick with what I currently got: a working mono and Rider based toolchain, unfit for production but at least not giving me any hustle whilst developing.

It's not all bad, if it would be I would have given up. But it feels like the v1.0 beta stuff you expect from a new ISV or project: things seem to work, sorta, but a lot has rough edges and is barely documented, and poking too hard will make it bleed.

perhaps in half a year things are better (but admitted, I've thought that too about v2.0)

Yeah! I'll just wait till you and JetBrains release the EAPs and then definitely will give it a try. No problems would mean no fun and no excitement.

kamiwa wrote:

Yeah! I'll just wait till you and JetBrains release the EAPs and then definitely will give it a try. No problems would mean no fun and no excitement.

Heh, well, let's say 'no challenges==no fun' problems... I can do without