Query in SQL v/s Query in Oracle
I am learning to execute query on SQL on my SQL server, right now I am using the SQL , I do not know whether but there are a lot of people who are using some other syntax, whenever we execute some queries occasionally we face some sort of dissimilarity in the query being produced in the end, so why does it happen , how are the queries in the SQL different from the SQL query , can anyone please explain to this question. I am waiting for your response.
Re: Query in SQL v/s Query in Oracle
I will ask you a few question on this topic Have you ever written any code that comprises of any sort of query while you use one database only to have it break when you toggled to some other database ? How frequently have you made your mind to restrict the functionality of your database by typing only essential SQL since you just were not certain whether your queries would function on a different database ? I think you should get back with answers to these questions
Re: Query in SQL v/s Query in Oracle
Do not worry I will give answer to those questions . I think you have typed ColdFusion code to control query results without acknowledging that the database can do the same operation quicker and more professionally. In all-uses , the database tends to be badly utilized in the majority of applications. Oracle9i and SQL Server 2000 – the difference is always the key to help. It is always important for the CF developer that will help them to write more transferable and database-smart applications.
Re: Query in SQL v/s Query in Oracle
One of the main differences between Oracle and SQL Server is in the action of chronological primary keys. To get an automatically generated chronological primary key for a table in SQL Server, you will have to make the column of the table as an IDENTITY column. On the other side Oracle, on the other hand, needs that you first make a sequence and then you will have to insert the values .
Re: Query in SQL v/s Query in Oracle
Although , these benefits of the SQL Server approach to chronological primary keys come with a cost - you will not be able to insert a value into an IDENTITY column. Thus, if you attempt to bulk import rows from a remote table into an insider one using an IDENTITY column, you will have to leave out the original column matching to the IDENTITY column. This results in discrepancies especially frustrating to handle correctly.