Description:
I would like to suggest a few changes to make things better.
- dotnet connector currently stores the decimal values as strings when it decodes them, before you can get it back as decimal value. For multiple decimal values this can be very slow. My suggestion is to implement a decimal parser directly from byte string to integer values what you can create a decimal value from at the end. (about 3x faster) And yes store the decimal immediately as decimal, it should be never intermedietaly stored as string.. its not required at all. Side note: it is important to use integers for calculating the decimal portions rather tha do it directly with decimal. Decimal calculations in c# are extremly slow. It would be 3x slower than current solution with strings.
- what would be EVEN better is to get to 2026+ in years and implement it server and client side to be able to tell the server to send and recive data in a binary format even for decimal values, instead of an encoded text for everything. So you can use an additional value what if it is added to the communication at start it tells the server to always try to send and recive in pure binary formats, and the connectors would simply work with the binary formats directly EVEN for decimal. And if this value is not present, than it falls back to the default ways, how it is doing things right now. For compatibility.
- SSL encryption: my suggestion here is to support a way where you can use a very long password like key to encode the communication on top of SSL if necessary. This password would be only known and stored on server side, and client side software. So the weakness of SSL could be overcome by this extra layer of protection. Bcos the password would be used to encode and decode alongside with SSL methods nobody can read anything without knowing this password. There is no challenge to be tricked with man in the middle attacks with relaying back and forte. Even if there would be a man in the middle server/sotware it could not understand anything ever. Obviously this protection would be added for more private solutions, where a server is not used publicly by millions, but only by ppl within a company. And they would be responsible for this password to be managed safely, distributing it to every client.
How to repeat:
Well for the decimal thing you should use like lets say at least 10 decimal values in database that can be queried. I would suggest to have a large amount of rows, like lets say 1 million+ records, and create a small project to do a loop with reader.Read method, and than its enough if you use the reader.GetValues() method for testing the difference btw an optimized parses and the current way. Its not necessary to literally do anything with the returned object[] values to mesure the difference.
Side note: there are a few unnecessary extra safety checkings in the code due to how it is coded. Like for example: when you call reader.GetValues() it uses a loop what you yourself create based on information in the reader.. so the data is precise already and exact. Which means when you call a a this[] or whatever code which than tests for range issues.. if your ordinal is valid or not.. that becomes totally unnecessary and with a million rows * column amount of calls it suddenly becomes 0,6+ second wasted time depending on the computers speed. This could be 3 seconds on a slower machine too. The connector is not a business level code, where you can be lazy and write code which looks very pretty, and tidy.. but at the same time its slow and has unnecessary checks and what not. Like calling property -> methods to get data where you could call a field value.. I mean this is c#.. business level means property usage is the good call, on something like this, where speed matters, optimization is king, unnecessary usage of properties is bad coding.
Suggested fix:
About the decimal parser: in c# the longest decimal is normally 31 characters long in string. 29 are the values and 1 for the sign and 1 for the dot.
The new decimal() method requires 3 integers (lo, mid, high) and a bool to tell if its negative, and a byte number to tell the dots position, i mean scale value.
So you can use that 5 value to represent the decimal, but also to calculate/build it from the byte array. As first step you decode the byte array into a character array, and work with that array to build the portions using the lo mid high and the other mentioned variables. I did test it on a large number of decimal values, aswell as on maximum decimal values and what not, and it works usually 3x times faster than parsing strings. Not to mention not allocating every time a new string is a bonus. The character array required is so small that you can have it always allocated as char[31] value 1 time globally never needed to be touched, other than used to parse.
And obviously if the mysql data would be for some reason a bigger value, than it should return with something of an error.. smilarly how it would do it now, since parsing and invalid string would cause an error too.
© 2026, Oracle Corporation and/or its affiliates