In SQL server to get value from field ,I need to use convert(varchar,column)
Data type is percentage float.
Value is like -0.07
Issue in QueryDsl
. I am not able to find similar way to convert data to string.
If I use .stringvalue method then its not giving same value and instead getting 0
So is there any way to convert value in QuerDsl?
Related
I am querying a SQL Server database that has a column of type datetimeoffset. I am using 'pyodbc' and SQL Server 2017. The datetime is being returned as strings as follows:
"b'\xe3\x07\n\x00\x0e\x00\x12\x00\x03\x00\x05\x00#\xe1\x9d\x18\x00\x00\x00\x00'"
Pandas doesn't recognize it as a timestamp and I have tried using Python 3 'struct' module to unpack it like this:
import struct
raw = 'b\xe3\x07\n\x00\x0e\x00\x12\x00\x03\x00\x05\x00#\xe1\x9d\x18\x00\x00\x00\x00'
unpacked, = struct.unpack('<Q', raw)
That errors out because 'raw' is a string. If I enter the string directly as an argument in 'unpack' it errors out because of wrong number of bytes.
How do I convert the column values to pandas datetime?
Additional Note:
This site indicates that the SQL Server uses a particular type that pyodbc doesn't handle natively as suggested by mostert. That said, they seem to have no problem retrieving a human-readable value.
[SOLVED] So the solution at this site does work. TIL: when adding the converter you need to get the type as an integer, in this case '-155'. This site has the integer codes for some other types
So the solution at this site does work. TIL: when adding the converter you need to get the type as an integer, in this case '-155'. This site has the integer codes for some other types
I've created one store procedure that returns the JSON. But it not return complete JSON only limited JSON returned. I used "For JSON auto" after Select statement. Have any Solution to get all JSON?
if you are using any Cast or covert operations. Use VARCHAR(MAX) instead of VARCHAR().
I have seen this issue in such cases.
Also if you are using the print output, then it is possible that the text might get truncated, but you can use the Select or Output parameter instead.
make the output parameter of type nvarchar(max)
or check this link :
Format Query Results as JSON with FOR JSON (SQL Server)
This might help
I found my solution here: https://learn.microsoft.com/en-us/sql/relational-databases/json/format-query-results-as-json-with-for-json-sql-server?view=sql-server-ver15#output-of-the-for-json-clause (same as above, but a specific section)
The issue was that I thought SQL Server was returning a single row/cell of JSON data because that is how SSMS displayed it. The truth is that it chops it into multiple rows.
I was retrieving the data in .NET using ExecuteScalar(), but I needed to use ExecuteReader(), and concatenate all rows together. Once I did that, I could deserialize the JSON without issue.
insert into mytable values(1,'06-06-2012');
why do we include date within single quotes here?!! However, we do not do the same while passing the value through parameterized query?!!
With literals, the SQL Server database engine parses the value into native format during query execution. The datetime value is parsed into an 8-byte native binary representation.
Parameter values are passed to SQL Server in native binary format so enclosurse are not used. The client API converts the parameter value according to the declared parameter data type and passes the binary value to SQL Server using a TDS protocol remote procedure call. SQL Server doesn't need to parse the value at all, although conversion might still be needed if the parameter data type doesn't match the data type needed in the query.
For example, if you pass a string parameter value of '06-12-2014' for a table data type of datetime, SQL Server will convert the parameter string value to datetime according to the session DATEFORMAT setting (could be interpreted as '2014-06-12' or '2014-12-06. Passing a native datetime parameter avoids the ambiguous date format because the task of converting the value to the native binary value was already done on the client.
We are inserting values into a SQL Server 2005 database column of type NUMERIC(19,5) from Perl. As long as the absolute values are .0001 or greater, it is working. However, when the values go to the 5th decimal place, Perl starts storing them in exponential format (-9e-05 instead of -0.00009), and then we get the error "Error converting data type varchar to numeric" from SQL Server. How do we prevent that and cause it to properly insert small numeric values?
We are using perl v5.8.5, DBI 1.56, DBD::Sybase 1.07, and SQL Server 2005.
The code is roughly the following, but I have removed the extraneous fields:
$invoice->{IL_UNITPRICE} = 0.09; # Actually comes from another database
$invoice->{IL_PRICEUNITCONV} = 0.001; # Actually comes from another database
$unitprice = $invoice->{IL_UNITPRICE} * -1 * $invoice->{IL_PRICEUNITCONV};
#$unitprice equals -9e-05 at this point.
$sth = $dbh->prepare('INSERT INTO foo ( bar ) VALUES ( ? )');
$sth->execute($unitprice);
The above line fails with error: DBD::Sybase::st execute failed: Server message number=8114 severity=16 state=5 line=2 server=baz text=Error converting data type varchar to numeric.
Try
$sth->execute(sprintf("%.6f",$unitprice));
To expand a bit -- When you pass a native float/double through the DBi interface it gets converted to a string, which, if you don't specify otherwise, uses Perl's default formatting conventions (imposed by the C compiler). The default is 6 digits precision, and if the number has more than that it's rendered in scientific notation.
To get fixed-point format you have to ask for it explicitly, using sprintf.
Actually I think using Math::Bigint and its associated Math::BigFloat would also solve this problem. Whenever I use floats or numbers of a sufficiently large size I use these modules so I don't have to throw sprintf's all over the place except when I really want to control the formatting.
I have a column with bigint datatype in SQL Server 2005.
I want to store 0347 in that.. (0 should not be removed) means their must be at least four value like: 0034 , 0007, 0423,4445.
SQL will not store the 0 if you use a bigint.
You could use
select right('00000000'+ltrim(Str(<bigIntField>)),4) as DisplayVal
Change the '4' to what size you want to zero fill the fields to.
You can't store a formatted value like that in an integer field. You'd need to store as a VARCHAR.
Unless you have a very good reason, I'd keep it as you have it in the DB, but just format the number for display in the UI.
As far as I know, you can't store formatted data in an integer type field.
Run sprintf or similar over the data when you get it out of the database instead.