SQL Rounding Problems in 2005 and 2000 - sql-server-2005

I have a value in the database which is 2.700000002. When I run a query in Management studio in SQL SERVER 2005 I get 2.7. But when I run in SQL SERVER 2000 query analyzer it comes 2.700000002.
2.70000002 is correct why is SQL SERVER 2005 trying to change the value by rounding it or selecting the floor value?

Exactly the same target server, database, datatype, processor, architecture etc?
If not, it's simply how the tools will display an approximate float value

Most things round off numbers for display.
~$ ghci
Prelude> 2.7
2.7
~$ irb
>> 2.7
=> 2.7
~$ python
>>> 2.7
2.7000000000000002
For interactive use, this is usually good enough — the only person to see the query analyzer is you, so why does it matter? For actual display, you should specify a format anyway. If you really need the exact value of "2.7", then you should be using a decimal type anyway, as countless articles and answers can tell you.

Related

SQL auto converts decimal to numeric when select & insert

I have SQL Server 2008 R2 and linked SQL Server 2012.
When I do the following
SELECT * INTO dbo.Local_table FROM dbo.Linked_table
all decimal columns automatically get converted into numeric.
What is the reason and how can I get rid of it?
This is automatic conversion that occurs with most SQL Servers. You'll find this happening with at least, but not limited to, server year versions 2000-2014. I don't know of a way to get rid of this restriction because it's a built in server feature which restricts arithmetic equations via query statements.
Here is another SO question/answer which might help you:
T-SQL Decimal Division Accuracy
Here is some MSDN for clarification:
https://msdn.microsoft.com/en-us/library/ms187746.aspx

Error Converting varchar to Int - Sql on Server vs SQL on local PC

I have a Query requiring Varchar to be converted into INT. Iam not currently posting the query itself as I do not believe the problem to be there.
I setup the query on my home PC using a backup from the servers SQL file. I have Server 2008 R2 installed on both machines.
The Query runs 100% on my PC but gives an error converting varchar to INT when run on the server.
Iam guessing there is a setting somewhere that is not the same? I have checked Regional settings and the problem is not there. any ideas?
The problem lies in how the query is evaluated. You have no guarantee or what order parts of the query will be evaluated in, so on one machine a filter may happen after a convert, on another it could do. Or the WHERE clause conditions can be evaluated in a different order
SQL is declarative, not procedural. With SQL you ask for what you want and the query optimiser honours that how it sees fit. In a procedural language (C#, Java etc) you'd control the execution order.
The reason is full described here: Why use Select Top 100 Percent?

How to determine SQL server version number for Compact edition 4 up to full sql server 2008?

Lot's of people have asked and been responded to about how to determine the version of the sql server using things like ##VERSION, or SERVERPROPERTY('productversion') but none of these work with sql server compact edition 4.
Is there some universally supported method to determine which sql server edition and version is in use through a sql query or ado.net code that works for compact edition all the way to full sql server?
I want to determine which exact edition / version of SQL server is in use so I know what type of paging query to issue from my code. Sql CE 4 uses a new format for paging queries same as sql server 2011 (denali) and 2005 and 2008 have their own method that is unsupported in CE 4.
I think the answer is that it's impossible but I just want to be sure I didn't overlook something.
I don't really work with SQL Server anymore but here is my attempt at this little problem.
For version 4 of compact edition the following should give you the version and build.
var ver = new System.Data.SqlServerCe.SqlCeConnection().ServerVersion;
And the following should give you the assembly version
var version = typeof(System.Data.SqlServerCe.SqlCeConnection).Assembly.GetName().Version;
Take a look at this blog post. It has a link to download a utility that detects which version of SQL Compact edition you're running. It also has a link to the source code for the utility which may be of interest to you.
You can use PowerShell , in versions of Windows 7 or newer , it comes pre- installed by default. Use the following command lines :
[System.Reflection.Assembly]::LoadFrom("SQLCeAssembly.dll").GetName().Version
Outputs this:
Major Minor Build Revision
----- ----- ----- --------
4 0 0 0
run this
SELECT SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'), SERVERPROPERTY ('edition')
See details here

Microsoft T-SQL to Oracle SQL translation

I've worked with T-SQL for years but I've just moved to an organisation that is going to require writing some Oracle stuff, probably just simple CRUD operations at least until I find my feet. I'm not going to be migrating databases from one to the other simply interacting with existing Oracle databases from an Application Development perspective. Is there are tool or utility available to easily translate T-SQL into Oracle SQL, a keyword mapper is the sort of thing I'm looking for.
P.S. I'm too lazy to RTFM, besides it's not going to be a big part of my role so I just want something to get me up to speed a little faster.
The language difference listed so far are trivial compared to the logical differences. Anyone can lookup NVL. What's hard to lookup is
DDL
In SQL server you manipulate your schema, anywhere, anytime, with little or no fuss.
In Oracle, we don't like DDL in stored procedures so you have jump through hoops. You need to use EXECUTE IMMEDIATE to perform a DDL function.
Temp Tables
IN SQL Server when the logic becomes a bit tough, the common thing is to shortcut the sql and have it resolved to a temp table and then the next step is done using that temp table.
MSSS makes it very easy to do this.
In Oracle we don't like that. By forcing an intermediate result you completely prevent the Optimizer from finding a shortcut for you. BUT If you must stop halfway and persist the intermediate results Oracle wants you to make the temp table in advance, not on the fly.
Locks
In MSSS you worry about locking, you have nolock hints to apply to DML, you have lock escalation to reduce the count of locks.
In Oracle we don't worry about these in that way.
Read Commited
Until recently MSSS didn't fully handle Read Committed isolation so you worried about dirty reads.
Oracle has been that way for decades.
etc
MSSS has no concept of Bitmap indexes, IOT, Table Clusters, Single Table hash clusters, non unique indexes enforcing unique constraints....
I get the impression most answers focus on migrating an entire database or just point to some differences between T-SQL and PL/SQL. I recently had the same problem. The Oracle database exists, but I need to convert a whole load of T-SQL scripts to PL/SQL.
I installed Oracle SQL Developer and ran the Translation Scratch Editor (Tools > Migration > Scratch Editor).
Then, just enter your T-SQL, choose the correct translation in the dropdown-list (it should default to 'T-SQL to PL/SQL'), and convert it.
I have to things to mention.
1) When I worked on Oracle 8, you could not do "Select #Result", you had to instead use the dummy table as follows "Select #Result from dual". Not sure if that ridiculousness still exists.
2) In the Oracle world they seem to love cursors and you better read up on them, they use them all the time AFAICS.
Good luck and enjoy,
it is not that different to MS SQL. Thankfully, I do not have to work with it anymore and I am back in the warm comfort of MS tools.
If you replace your ISNULL and NVL nonsense with COALESCE, it'll work in T-SQL and PL/SQL!
It's not trivial to map them back and forth, so I doubt there's a tool that does it automatically. But this link might help you out: http://vyaskn.tripod.com/oracle_sql_server_differences_equivalents.htm
The most important differences for plain T-SQL are:
NVL replaces ISNULL
SYSDATE replaces GETDATE()
CONVERT is not supported
Identity columns must be replaced with sequences <-- not technically T- or PL/ but just SQL
Note. I assume you do not use the deprecated SQL Server *= syntax for joins
#jodonell: The table you link to is a bit outdated, oracle has become somewhat more standards compliant after 9i supporting things like CASE and ANSI outer joins
I have done a few SQL server to oracle migrations. There is no way to migrate without rewriting the backend code. Too many differences between the 2 databases and more importantly differences between the 2 mind sets of the programmers. Many managers think that the 2 are interchangeable, I have had managers ask me to copy the stored procedures from SQL server and compile them in oracle, not a clue! Toad is by far the best tool on the market for supporting an oracle application. SQL developer is ok but was disappointing compared to toad. I hope that oracle will catch their product up to toad one day but it is not there yet. Have a good day :) chances are if you are migrating to oracle it is for a reason and in order to meet that requirement you will need to rewrite the back end code or you will have many issues.
In Oracle SQL Developer, there is a tool called Translation Scratch Editor. You can find it from Tools > Migration.
The Oracle SQL Developer is a free download from Oracle and it is an easy install.
If you're doing a one-off conversion, rather than trying to support two versions, you must look at Oracle Migration Workbench. This tool works with Oracle's SQLDeveloper (which you really should have if you are working with Oracle). This does a conversion of the schema, data, and some of the T-SQL to PL/SQL. Knowing both well, I found it did about an 80% job. Good enough to make it worth while to convert the bulk of procedures, and hand convert the remainder "tougher" unknown parts.
Not cheap ($995) but this tool works great: http://www.swissql.com/products/sql-translator/sql-converter.html
A few people have mentioned here converting back and forward. I do not know of a tool to convert from MSSQL to Oracle, but I used the free MS tool to convert a Oracle db to MSSQL and it worked for me and converted a large db with no problems I can call. It is similar to the Access to MSSQL tool that MS also provide for free. Enjoy
jOOQ has a publicly available, free translator, which can be accessed from the website here: https://www.jooq.org/translate
It supports DML, DDL, and a few procedural syntax elements. If you want to run the translation locally via command line, a license can be purchased and the command line works as follows:
$ java -cp jooq-3.11.9.jar org.jooq.ParserCLI -t ORACLE -s "SELECT substring('abcde', 2, 3)"
select substr('abcde', 2, 3) from dual;
See: https://www.jooq.org/doc/latest/manual/sql-building/sql-parser/sql-parser-cli
(Disclaimer, I work for the vendor)

Firebird's SQL's Substring function not working

I created a view on a machine using the substring function from Firebird, and it worked. When I copied the database to a different machine, the view was broken. This is the way I used it:
SELECT SUBSTRING(field FROM 5 FOR 15) FROM table;
And this is the output on the machine that does not accept the function:
token unknown: FROM
Both computers have this configuration:
IB Expert version 2.5.0.42 to run the queries and deal with the database.
Firebird version 1.5 as server to database.
BDE Administration version 5.01 installed, with Interbase 4.0 drivers.
Any ideas about why it's behaving differently on these machines?
Make sure Firebird engine is 1.5 and there's no InterBase server running on this same box on the port you expected Firebird 1.5.
Make sure you don't have any UDF called 'substring' registered inside this DB so that Firebird is expecting different parameters.
Different engine versions?
Have you tried naming that expression in the result?
SELECT SUBSTRING(field FROM 5 FOR 15) AS x FROM table;