In my post here I mentioned that we had to use a string SQLTag instead of a float because the number was optional and could be stored in the database as either a valid number or null.
Do James’ posts here and here suggest that this problem may be already solved in the next version (or at least solvable)?
I don’t think that what James was referring to applies to your issue. He was talking about inserting nulls into a dataset. Your issue seems to be rooted in Python itself becoming more strict on string formatting. I still think your issue exists and may actually be out of our hands.
Maybe I wasn’t clear here - I was referring to the original problem of not being able to read a relational database value into a SQLTag when it could be null - when this happens, the SQLTag was not set to None, it was set to zero (if a float SQLTag). This is what forced us to use code to set the value of a string SQLTag to an empty string if the relational database value was null. This seems to be exactly the issue James was addressing.
The issue that was mentioned in those posts pertained to existing datasets in Ignition. Ignition properly handled pulling in integers into databases, it would coerce a value of “null” from the DB as “None” in python, which would leave that particular cell in a table blank, as expected. However, if you tried to edit the dataset within Ignition, and change a cell that had a value to “None”, it would default the cell to 0, instead of leaving the cell blank.
When I bring in values from a database into SQLTags, it doesn’t seem to matter if I use String or Float for the datatype of the tag, it will either have a value or say “null”. So you’re saying when you use a SQLTag with datatype “Float4” or “Float8”, and the value in the DB is null, the value in the SQLTags Browser says “0”?
We’ve carried out some further testing and it seems that the handling and display of null values is inconsistent across different SQLTags. I have attached a window which allows the entry of None and valid values into a number of different SQLTags. These values are then displayed in a range of controls. To run this window you will have to enter the following Float4 SQLTags:[code]Tags
float_expression (with the expression pointing to the value of float_expression2)
float_expression2 (with the expression set manually to null or 1.23
float_memory
float_query (with the SQL query left blank)
Client
float_client
[/code]Note that not entering a query tag SQL query means it will be displaying with an error overlay which we ignore for this test.
The following summarises the results of the test:
All SQLTags
Set to value of 1.23
Client tag
Set to None
Memory tag
Set to None
Query tag
Set to None
Expression tag
Cannot be set to None directly. Instead it is bound to the value of float_expression2 which is set using the SQLTags Browser.
Thanks for the in depth testing. I’ll import this here on my system and make sure that I get the same results and then see if there is some sort of solution we can come up with.
Ok, so I’ve added a ticket in our system to make SQL Tags have more consistent behavior when their value is set to null. How the components handle these null values is a different issue though and that will require more time and thought as to what the appropriate behavior should be for each component.
Long story short, the fix that James mentioned does not address your issue but we are working on some improvements to the way that tags handle null values.
Nothing to add, but I just want to say that AlThePal is one poster that I zero in on every time. It’s rare that I don’t learn something when he shows up here. 
Thank you Step7 
My lack of knowledge knows no bounds!
Dave, thanks for looking at this. For any others reading this, it’s worth pointing out we have a working solution - we read the value from the relational database (which can be either a valid float or null into a string SQLTag, using code to set the SQLTag to a blank string if the value is null. We then use a Formatted Text Field for data entry, using a regular expression to accept either a valid float or a blank string. We then reverse the process when updating the database, setting the value to null if the string is blank.
Thanks for posting the workaround you came up with.