Firebird UInt32 is cast to BigInt
See original GitHub issueLinqToDB-Version : 2.3.0 Firebird-Version: 2.1.3 SQL-Dialect: 1
Hello,
I run a simple SQL that searches for a specific number:
UInt32 number = 50;
using (var context = new DbContext())
{
var p = context.Persons.FirstOrDefault(p1 => p1.Age == number)
}
In the resulting sql the Age property is cast to a BigInt. The mapped property is UInt16.
The problem is that BigInts are not supported by SQL-Dialect 1.
Issue Analytics
- State:
- Created 5 years ago
- Comments:10 (10 by maintainers)
Top Results From Across the Web
CAST()
Description: CAST converts an expression to the desired datatype or domain. If the conversion is not possible, an error is raised. Result type:...
Read more >firebird - Alter a Column from INTEGER To BIGINT
Firebird will not convert existing data from INTEGER to BIGINT , instead it will create a new format version for the table.
Read more >How to convert integer, decimal, double or date to string?
How to convert integer, decimal, double or date to string? This is very simple, since Firebird's built-in CAST operator does this very well:...
Read more >[Firebird-devel] ALTER TABLE question
Hi all! I see this same behavior in FB1.5.2, Vulcan, and FB2 Alpha 2. ... -Cannot change datatype for N. Conversion from base...
Read more >Firebird SQL string to real, string to integer
2 easy firebird sql functions to convert any string to real or integer. String to real. MySQL. CREATE OR ALTER FUNCTION string_to_float (ch ......
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I plan to look at it today/tomorrow so it will be included into next release
Moving it to 3.0 milestone as it looks like requested functionality could be implemented by configuring provider/mapping schema and proper dialects support is something we plan to implement in 3+ version.