T-SQL: Disable default FLOAT rounding when using Table with its View - tsql

Question

Good day!
Here is the problem of float rounding when I want insert data into Table using its View.
Data NEED to store as varchar in Table.
Table:
CREATE TABLE [dbo].[TestTableFloat_E]
(
[id] [int] IDENTITY(1,1) NOT NULL,
[FloatField] [varchar](100) NOT NULL
)
View:
ALTER VIEW [dbo].[TestTableFloat]
AS
SELECT id
,Convert(float, FloatField) as FloatField
FROM dbo.TestTableFloat_E
The data, what I select from Table using its View - have to have float type (field FloatField).
I can't insert data into Table, if i need, I need do it with its View. So, I can't (this is task rule) insert data directly into Table, just with View. I create trigger to insert data:
CREATE TRIGGER [dbo].[tr_TestTableFloatInsert]
ON [dbo].[TestTableFloat]
INSTEAD OF INSERT
AS
BEGIN
SET NOCOUNT ON;
insert into TestTableFloat_E (FloatField)
select FloatField
FROM INSERTED
Actions: I try insert data into TestTableFloat_E (table) with help of its View (TestTableFloat), rises trigger and insert data into table.
Problem: When I insert float number, I have rounding, that I don't need:
insert TestTableFloat (FloatField)
select 123.123456
I have 123,123 in the Table TesttableFloat. I need it doesn't round, I have to have 123.123456
What can it be?

Answer 1

You can have it store more digits, but it's going to switch to scientific notation:
CREATE TRIGGER [dbo].[tr_TestTableFloatInsert]
ON [dbo].[TestTableFloat]
INSTEAD OF INSERT
AS
BEGIN
SET NOCOUNT ON;
insert into TestTableFloat_E (FloatField)
select CONVERT(varchar(100),FloatField,2)
FROM INSERTED
END
Which ends up storing 1.231234560000000e+002 into the table.
From CAST and CONVERT:
When expression is float or real, style can be one of the values shown in the following table. Other values are processed as 0.
0 (default)
A maximum of 6 digits. Use in scientific notation, when appropriate.
1
Always 8 digits. Always use in scientific notation.
2
Always 16 digits. Always use in scientific notation.
Insert usual caveats about futility of expecting float and a decimal representation of the same to always be exactly convertible, and of using inappropriate data types to store particular types of data
It would appear the best data type to use for this data would be decimal with appropriate scale and precision, which is neither of the types you're working with. But you claim that those are the "required" types. E.g. if the view uses a decimal instead of a float, the stored varchar(100) value is exactly as expected.