how to calculate one column from another columns? - sql

In monetdb I created a table:
create table extractedcatalog(id int, ra double, decl double, x double, y double, z double);
ra,decl are all inserted into tables already, now I want to calculate x,y,z from ra,decl columns. In sql I executed like this:
update extractedcatalog set x = (cos(radians(decl))*cos(radians(ra)));
but i got response:
connection terminated
Is there any problem with my sql query?
Thanks very much!

Please indicate your platform and MonetDB version. A Connection Termination message indicates a loss of contact between your client and server. You may look into the Merovingian log file for further clues on the underlying cause.

Related

SQL ORACLE : Is it possible to convert NUMBER with CHAR (varchar2 datatype) to NUMBER datatype

I have a big problem right now and I really need your help, because I can't find the right answer.
I am currently writing a script that triggers a migration process from a table with raw data (data we received from an excel file) to a new normalized schema.
My problem is that there is a column PRICE (varchar2 datatype) with a bunch of traps. For example: 540S, 25oo , I200 , S000 .
And I need to convert it to the correct NUMBER(9,2) format so I can get: 5405, 2500, 1200, 5000 as NUMBER for the previous examples and INSERT INTO my_new_table.
Is there any way I can parse every CHAR of these strings that verify certain conditions?
Or others better way?
Thank you :)!
One of the wonderful things about Oracle that some other DBs lack, is the TRANSLATE function:
SELECT TRANSLATE(number, 'SsIilOoxyz', '5511100') FROM t
This will convert:
S, s to 5
I, i and l to 1
O, o to 0
Remove any x, y or z from the number
The second and third arguments to translate define what characters are to be mapped. If the first string is longer than the second then anything over the length of the second is deleted from the resulting string. Mapping is direct based on position:
'SsIilOoxyz',
'5511100'
Look at the columns of the characters; the character above is mapped to the character below:
S->5,
s->5,
I->1,
i->1,
l->1,
O->0,
o->0,
x->removed,
y->removed,
z->removed`
You can use translate() and along with to_number(). Your rules are not exactly clear, but something like this:
select to_number(translate(price, '0123456789IoS', '012345678910'))
from t;
This replaces I with 1, o with 0, and removes S.

In a hive query can you specify a condition like "where coulm1 is INT"?

I would like to query a hive table only for those rows that have coulmn1 as integer value only. Due to some data corruption, without this check I am getting a lot of junk data, I would like to get rid of that data by applying where column1 is INT kind of condition, but I couldn't find anything like that in hive. Could anyone suggest how I could do it?
Without any example data, I would suggest something very basic like this:
define column X as STRING
check that X = cast(cast(X as INT) as STRING)
You may have to add some tolerance to blank space, zero-padding, etc. depending on the way your "integers" are actually formatted.
Found a solution that is working :
I could add a Double number check like below, anything other than just numbers will make it null. Also, the valid numbers for the column will never cross the Double range.
So we could do something like below I guess:
"select * from table_example where cast(column1 as double) is not null"

CHECK Constraint for SUM failing on double precision column

I'm trying to understand a failure on my CHECK constraint in SQL Server 2008 R2 (the same problem occurs on SQL Server 2012).
My sql command just update the amount by 126.3 on two columns and the constraint checks if the sum of two columns match a third column.
Below are the steps to reproduce the problem:
CREATE TABLE FailedCheck ( item VARCHAR(10), qty_total DOUBLE PRECISION, qty_type1 DOUBLE PRECISION, qty_type2 DOUBLE PRECISION )
ALTER TABLE FailedCheck ADD CONSTRAINT TotalSum CHECK(qty_total = (qty_type1 + qty_type2));
INSERT INTO FailedCheck VALUES ('Item 2', 101.66, 91.44, 10.22);
UPDATE FailedCheck SET qty_total = qty_total + 126.3, qty_type1 = qty_type1 + 126.3
Column qty_total must contain the sum of (qty_type1 and qty_type2). All columns are 'Double precision'. If I change the value from 126.3 to 126, it works, I've tested other values (int and double) and couldn't understand why sometimes it works and sometimes doesn't.
What's wrong with my CHECK constraint ?
PS: Sorry for my english, it's not my primary language.
You decided for a floating point data type which only holds an approximate value - quite precise, but only up to an extent. 1.3 may well be stored as 1.299999999999998 or something along the lines. So the sum for the approximate values of 91.44 and 10.22 may happen to be exactly the approximate value for 101.66, but may also be very slightly different.
Never compare floating point values with the equal sign (=).
And better don't use floting point types in the first place, if not really, really needed. Use DECIMAL instead.

Why is this SQL not working as a stored procedure, but works fine as a regular query?

The TrackingData table is inside a database named Tracking. The stored procedure is being run inside the same database. I get data back with the query, but not with the SP.
SELECT *
FROM
dbo.TrackingData
LEFT OUTER JOIN SSMain.dbo.EmailCampaignTracking ON (dbo.TrackingData.emailCampaginTrackingID = SShMain.dbo.EmailCampaignTracking.emailCampaignTrackingID)
LEFT OUTER JOIN SSMain.dbo.EmailCampaigns ON (SSMain.dbo.EmailCampaignTracking.emailCampaignID = SSMain.dbo.EmailCampaigns.emailCampaignID)
LEFT OUTER JOIN SpinStitchMain.dbo.EmailListAddresses ON (SSMain.dbo.EmailCampaignTracking.emailAddressID = SSMain.dbo.EmailListAddresses.emailAddressID)
WHERE
dbo.TrackingData.lattitude = 33.8322 AND
dbo.TrackingData.longitude = -78.6491 and
dbo.TrackingData.projectID = 131
CREATE PROCEDURE dbo.sel_Track_HitsByLatLong(
#latitude decimal(18,15),
#longitude decimal(18,15),
#projectID int
)
AS
BEGIN
SELECT *
FROM
dbo.TrackingData
LEFT OUTER JOIN SSMain.dbo.EmailCampaignTracking ON (dbo.TrackingData.emailCampaginTrackingID = SSMain.dbo.EmailCampaignTracking.emailCampaignTrackingID)
LEFT OUTER JOIN SSMain.dbo.EmailCampaigns ON (SSMain.dbo.EmailCampaignTracking.emailCampaignID = SSMain.dbo.EmailCampaigns.emailCampaignID)
LEFT OUTER JOIN SSMain.dbo.EmailListAddresses ON (SSMain.dbo.EmailCampaignTracking.emailAddressID = SSMain.dbo.EmailListAddresses.emailAddressID)
WHERE
dbo.TrackingData.lattitude = #latitude AND
dbo.TrackingData.longitude = #longitude and
dbo.TrackingData.projectID = #projectID
END
Edit:
Turns out the numbers are getting zeros added to the end of them: 33.832200000000000
This has never happened befor an dnot sure what has changed. They get added when the prcedure is run.
i would bet that it has to do with a conversion issue. Is TrackingData.lattitude and TrackingData.longitude really decimal(18,15) in your table?
can you replace the parameters in the SP with the two values in your first query and get the answer back? If so, then it's somewhere in the conversion when you are passing the parameters in.
I work with Lat's and Long's all the time - and I used to have DECIMAL(18,15) as the datatype.
I also had this problem :(
For me, it was a LOCALIZATION issue -> when a user from a non en-us/en-gb, etc.. location hit my site, the PERIOD was replaced with a COMMA. so i was trying to pass in 123,111 for a decimal value. fail. This means that, in my .NET application, the current thread's CultureInfo was getting auto set to the locale of the users connection (eg. es for spain, etc).
.
(for a .NET product/project)....
Try making sure u set the thread's cultureinfo to en-gb (that IS proper english, after all .. swipe!) and then seeing if the stored proc now works.
Too me -aaaaaagggggeeeeesssssss- to fix that bug :) u see, it always worked on my local machine (en-au) and as a query ... :)
good luck :)
Just as a FYI, latitude and longitudes having fifteen decimal digits of precision after the decimal is almost certainly excess precision. Near the equator, a precision of six digits corresponds to 11 centimeter (4.3 inch) resolution. Nine more orders of magnitude is well on the way to molecular size precision....
What does this give you outside of the stored proc?
...
WHERE
dbo.TrackingData.lattitude = CAST(33.8322 as decimal(18,15)) AND
dbo.TrackingData.longitude = CAST(-78.6491 as decimal(18,15)) and
dbo.TrackingData.projectID = CAST(131 as int)
Then add this the stored proc
SELECT #latitude, #longitude, #projectID
Between this, you should see exactly what the stored proc is working with and what the query returns when datatypes match
OK, so I changed the Lat and Long parameters to type of FLOAT. It works perfect now. I wasn't thinking that when sending the params as decimal(18,15), that it would add zeros to the end if the precision was lass than 15. Thanks to everybody who helped out with this.
Do you have access to SQL Server profiler? If so I would recommend catching a trace of what is actually being passed to the execute function as the parameters. Perhaps there is a precision problem with the values being passed to the SP. You think its 131 but you are getting 131.00000000000000000000000000001 instead.

Is there a 'greatest' function in db2?

I found in MYSQL and apparently other database engines that there is a "greatest" function that can be used like: greatest(1, 2, 3, 4), and it would return 4. I need this, but I am using IBM's DB2. Does anybody know of such an equivalent function, even if it only accepts 2 parameters?
I found somewhere that MAX should do it, but it doesn't work... it only works on selecting the MAX of a column.
If there is no such function, does anybody have an idea what a stored procedure to do this might look like? (I have no stored procedure experience, so I have no clue what DB2 would be capable of).
Why does MAX not work for you?
select max(1,2,8,3,1,7) from sysibm.sysdummy1
gives me
1
---------------
8
1 record(s) selected.
As Dave points out, MAX should work as it's overloaded as both a scalar and a column function (the scalar takes 2 or more arguments). This is the case in DB2 for LUW, DB2 for z/OS and DB2 for i5/OS. What exact version and platform of DB2 are you using, and what is the exact statement you are using? One of the requirements of the scalar version of MAX is that all the arguments are "compatible" - I suspect there may be a subtle type difference in one or more of the arguments you're passing to the function.
On Linux V9.1, the "select max (1,2,3) ..." gives -
SQL0440N No authorized routine named "MAX" of type "FUNCTION" having
compatible arguments was found. SQLSTATE=42884
It is a scalar function requiring either a single value or a single column name. On z/os, it behaves differently.
However, It does work as expected on Linux 9.5.
Two options:
What about sorting the column in descending and grabbing the top 1 row?
According to my "SQL Pocket Guide", MAX(x) returns the greatest value in a set.
UPDATE: Apparently #1 won't work if you are looking at columns.
It sounds crazy, but no such function exists in DB2, at least not in version 9.1. If you want to select the greater of two columns, it would be best to use a case expression.
You can also define your own max function. For example:
create function importgenius.max2(x double, y double)
returns double
language sql
contains sql
deterministic
no external action
begin atomic
if y is null or x >= y then return x;
else return y;
end if;
end
Defining the inputs and outputs as doubles lets you take advantage of type promotion, so this function will also work for integers. The "deterministic" and "no external action" statements help the database engine optimize use of the function.
If you want another max function to work for character inputs, you'll have to give it another name.
Please check with following query:
select * from table1 a,
(select appno as sub_appno,max(sno) as sub_maxsno from table1 group by appno) as tab2
where a.appno =tab2.sub_appno and a.sno=tab2.sub_maxsno