on a specific page that I am developping; I have 2 drop down lists that I have to connect, the first one shows XLAT operands ( equals, different, greater than...) and the second shows values (0,1,2,3,4). The problem is how can I translate the operands mathematically, so that when I choose 'greater than 2' for example the system gets it (>2)? It should be done with peoplecode? schema
Thanks!
You would need to do an Evaluate or If/Else over the XLAT from the operands.
What do you want to achieve? Post your code so I can suggest if you go to a SQL statement or PeopleCode.
Related
I am trying to implement a use-case in Mule4 where a tour needs to be assigned to a user if it has not already been assigned.
I was hoping that I could implement it using Mule db:insert component and using INSERT WHERE NOT EXISTS SQL script as below.
INSERT INTO TL_MAPPING_TOUR(TOURNO,TLID,SYSTEM) select :tourno,:tlid,:system from DUAL
where not exists(select * from TL_MAPPING_TOUR where (TOURNO=:tourno and TLID=:tlid and SYSTEM=:system))
However, this is resulting in Mule Exception
Message : ORA-01722: invalid number
Error type : DB:BAD_SQL_SYNTAX
TL_MAPPING_TOUR table has an id column (Primary Key), but that is auto-generated by a sequence.
The same script, modified for running directly in SQL developer, as shown below, is working fine.
INSERT into TL_MAPPING_TOUR(TOURNO,TLID,SYSTEM)
select 'CLLO001474','123456789','AS400'
from DUAL
where not exists(select * from TL_MAPPING_TOUR where (TOURNO='CLLO001474' and TLID='123456789' and SYSTEM='AS400'));
Clearly Mule db:insert component doesn't like the syntax, but it's not very clear to me what is wrong here. I can't find any INSERT WHERE NOT EXISTS example implementation for the Mule4 Database component either.
stackoverflow page https://stackoverflow.com/questions/54910330/insert-record-into-sql-server-when-it-does-not-already-exist-using-mule directs to page not found.
Any idea what is wrong here and how to implement this in Mule4 without using another Mule4 db:select component before db:insert?
I don't know "mule4", but this:
Message : ORA-01722: invalid number
doesn't mean that syntax is wrong (as you already tested it - the same statement works OK in another tool).
Cause: You executed a SQL statement that tried to convert a string to a number, but it was unsuccessful.
Resolution:
The option(s) to resolve this Oracle error are:
Option #1: Only numeric fields or character fields that contain numeric values can be used in arithmetic operations. Make sure that all expressions evaluate to numbers.
Option #2: If you are adding or subtracting from dates, make sure that you added/substracted a numeric value from the date.
In other words, it seems that one of columns is declared as NUMBER, while you passed something that is a string. Oracle performed implicit conversion when you tested the statement in SQL Developer, but it seems that mule4 didn't and hence the error.
The most obvious cause (based on what you posted) is putting '123456789' into TLID as other values are obviously strings. Therefore, pass 123456789 (a number, no single quotes around it) and see what happens. Should work.
SQL Developer is too forgiving. It will convert string to numbers and vise versa automatically when it can. And it can a lot.
Mulesoft DB connector tries the same but it is not as succefule as native tools. Pretty often it fails to convert, especially on dates but this is not your case.
In short - do not trust too much data sense of Mulesoft. If it works - great! Otherwise try to eliminate any intelligence from it and do all conversions in the query and better from the string. Usually number works fine but if doesn't - use to_number function to mark properly that this is the number.
More about this is here https://simpleflatservice.com/mule4/AvoidCoversionsOrMakeThemNative.html
I have a WordPress query that is ordered by a numeric meta value, however, the result of the query is slightly out of order.
Here is the query:
<?php query_posts('post_type=rushmoor&meta_key=subaru_driver_best_lap&orderby=meta_value_num&order=asc');?>
The result of the query can be seen here:
http://www.subarurallyexperience.co.uk/rushmoor/ranking/
It is mostly in order, but there are some cases where its out of order, for example 1st and 2nd place are currently backwards (02.03.44 should be before 02.03.66).
I have tried re-writing the query a number of different ways to deal with this issue but I haven't been having any luck.
I am honestly not even certain WHY these are out of order.
Can anyone shed any light on this?
I suspect it's because you're using meta_value_num as your orderby. MySQL will try to parse the values as numbers, get as far as 02.03, then hit a second decimal point, at which point it'll give up. So the order of 02.03.44 and 02.03.66 will be arbitrary - it's only comparing 2.03 with 2.03.
If all the values in the database are of the format xx.xx.xx, you should be fine using ordering by meta_value instead. You'd only have problems if (for example) you stored one time as 2.03.44 and the other as 02.03.66, in which case an alpha sort would put the 0 before the 2.
Edit
Just to confirm the above, the WordPress source shows meta_value_num adds 0 to the meta value to treat it as numeric. The following query in MySQL:
select '02.03.44' + 0, '02.03.66' + 0 from dual
returns 2.03 for both.
I have two tables defined for actual and expected with exactly the same schema. I insert two rows into the expected table with say Ids of 2, 1.
I run
INSERT INTO actual EXEC tSQLt.ResultSetFilter 1, '{statement}'
to populate the actual then
EXEC tSQLt.AssertEqualsTable #expected = 'expected' , #actual = 'actual'
to compare the results.
Even though the data is in a different order (Ids are 1, 2 in the actual), the test passes.
I confirmed that the data was different by adding SELECT * FROM actual and SELECT * FROM expected in the test and running the test on its own with tSQLt.Run '{test name}'.
Does anyone know if this is a known bug? Apparently it is supposed to check per row so the ordering should be checked. All the other columns are NULL that are returned it is just the ID column that contains a value.
Unless an order by clause is specified in the select statement, the order isn't guaranteed by SQL server (see the top bullet point at this MSDN page) - although in practice it is often ordered as you might expect.
Because of this, I believe that tSQLt looking for non-identical and identical rows makes sense - but checking the order doesn't - otherwise the answer could change at the whim of SQL server and the test would be meaningless (and worse - intermittently failing!). The tSQLt user guide on AssertEqualsTable states that it checks the content of the table, but not that it checks the ordering therein. What leads you to conclude that the order should be being checked as well? I couldn't find mention of it.
If you need the order to be checked, you could insert both expected and actual results into a temporary table with an identity column (or use ROW_NUMBER) and check the resultant table - if the order is different then the identity cols would be different.
There is a similar method documented here on Greg M Lucas' blog.
Relying on the order returned from the table without an order by clause is not recommended (MSDN link) - so I'd suggest including one in your application's call to the statement, or if an SP within it if the order of returned rows is important.
As we have two options to intercept the null values coming from database...
ISNull
Coalesce
Following are the ways to write the query for the above two functions...
Select IsNull(Columnname, '') As validColumnValue From TableName
Select Coleasce(Columnname, '') As validColumnValue From TableName
Query - Which should be prefered in which situation and why?
This has been hashed and re-hashed. In addition to the tip I pointed out in the comment and the links and explanation #xQbert posted above, by request here is an explanation of COALESCE vs. ISNULL using a subquery. Let's consider these two queries, which in terms of results are identical:
SELECT COALESCE((SELECT TOP (1) name FROM sys.objects), N'foo');
SELECT ISNULL((SELECT TOP (1) name FROM sys.objects), N'foo');
(Comments about using TOP without ORDER BY to /dev/null/ thanks.)
In the COALESCE case, the logic actually gets expanded to something like this:
SELECT CASE WHEN (SELECT TOP (1) ...) IS NULL
THEN (SELECT TOP (1) ...)
ELSE N'foo'
END
With ISNULL, this does not happen. There is an internal optimization that seems to ensure that the subquery is only evaluated once. I don't know if anyone outside of Microsoft is privy to exactly how this optimization works, but you can this if you compare the plans. Here is the plan for the COALESCE version:
And here is the plan for the ISNULL version - notice how much simpler it is (and that the scan only happens once):
In the COALESCE case the scan happens twice. Meaning the subquery is evaluated twice, even if it doesn't yield any results. If you add a WHERE clause such that the subquery yields 0 rows, you'll see similar disparity - the plan shapes might change, but you'll still see a double seek+lookup or scan for the COALESCE case. Here is a slight different example:
SELECT COALESCE((SELECT TOP (1) name FROM sys.objects
WHERE name = N'no way this exists'), N'foo');
SELECT ISNULL((SELECT TOP (1) name FROM sys.objects
WHERE name = N'no way this exists'), N'foo');
The plan for the COALESCE version this time - again you can see the whole branch that represents the subquery repeated verbatim:
And again a much simpler plan, doing roughly half the work, using ISNULL:
You can also see this question over on dba.se for some more discussion:
Performance difference for COALESCE versus ISNULL?
My suggestion is this (and you can see my reasons why in the tip and the above question): trust but verify. I always use COALESCE (because it is ANSI standard, supports more than two arguments, and doesn't do quite as wonky things with data type precedence) unless I know I am using a subquery as one of the expressions (which I don't recall ever doing outside of theoretical work like this) or I am experiencing a real performance issue and just want to compare to see if COALESCE vs. ISNULL has any substantial performance difference (which outside of the subquery case, I have yet to find). Since I am almost always using COALESCE with arguments of like data types, I rarely have to do any testing other than looking back at what I've said about it in the past (I was also the author of the aspfaq article that xQbert pointed out, 7 years ago).
begin humor: The 1st, the 2nd will never work it's spelled wrong :D END humor
---Cleaned up response---
Features of isNull(value1,value2)
Only supports 1 valuation, if the first is null, the 2nd will be used, so if its null too you get null back!
is non-ANSI standard. Meaning if database portability is an issue, don't use this one
isnull(value1,value2) will return the datatype for Value1
will return the datatype for the selected value and fail when implicit conversions can't occur
Features of Coalesce(Value1, Value2, value3, value...)
Supports multiple valuations of Null; basically will pull in the first non-null value from the list. if all values are null in list, null is returned.
is ANSI-standard meaning database portability shouldn't be an issue.
will return the datatype for the selected value and fail if all fields in the select do not return the same datatype.
So to answer the question directly:
It depends on the situation if you need to develop SQL that
is DB independent; coalesce is more correct to use.
allows for multiple evaluations; coalesce is more correct (of course you could just embed isnull over and over and over...) but put that under a performance microscope, and coalesce may just win. (i've not tested it)
are you using a db engine that supports isNull? (if not use coalesce)
how do you want type casting handled? implicitly or not.
---ORIGINAL------
is null only supports 2 evaluations
coalesce supports many more... coalesce (columnName1, ColumnName2, ColumnName3, '')
coalesce returns datatype similar to that of case evaluation, whereas isnull returns datatype of first in list. (which I found interesting!)
As to when to use which. you'd have to investigate by looking at execution plan of both on SQL 2008 and 2005, different versions different engines different ways to execute.
Furthermore coalesce is ansii standard, isnull is engine specific. Thus if you want greater portability between dbengines use coalesce.
More info here aspfaq
or here msdn blog
you may take this onto consideration.
ISNULL function required two parameters: the value to check and the replacement for null values
2.COALESCE function works a bit different COALESCE will take any number of parameters and return the first non-NULL value , I prefer COALESCE over ISNULL 'cause
meets ANSI standarts, while ISNULL does not.
I hope you found the answer to your question.
I have a SQL stored proc that returns a dataset to ASP.NET v3.5 dataset. One of the columns in the dataset is called Attend and is a nullable bit column in the SQL table. The SELECT for that column is this:
CASE WHEN Attend IS NULL THEN -1 ELSE Attend END AS Attend
When I execute the SP in Query Analyzer the row values are returned as they should be - the value for Attend is -1 is some rows, 0 in others, and 1 in others. However, when I debug the C# code and examine the dataset, the Attend column always contains -1.
If I SELECT any other columns or constant values for Attend the results are always correct. It is only the above SELECT of the bit field that is behaving strangely. I suspect it has something to do with the type being bit that is causing this. So to test this I instead selected "CONVERT(int, Attend)" but the behavior is the same.
I have tried using ExecuteDataset to retrieve the data and I have also created a .NET Dataset schema with TableAdapter and DataTable. Still no luck.
Does anyone know what is the problem here?
Like you, I suspect the data type. If you can change the data type of Attend, change it to smallint, which supports negative numbers. If not, try changing the name of the alias from Attend to IsAttending (or whatever suits the column).
Also, you can make your query more concise by using this instead of CASE:
ISNULL(Attend, -1)
You've suggested that the Attend field is a bit, yet it contains three values (-1,0,1). A bit, however, can only hold two values. Often (-1, 0) when converted to an integer, but also possible (0, 1), depending on whether the BIT is considered signed (two's compliment) or unsigned (one's compliment).
If your client (the ASP code) is converting all values for that field to a BIT type then both -1 and 1 will likely show as the same value. So, I would ensure two things:
- The SQL returns an INTEGER
- The Client isn't converting that to a BIT
[Though this doesn't explain the absence of 0's]
One needs to be careful with implicit conversion of types. When not specifying explicitly double check the precidence. Or, to be certain, explicitly specify every type...
Just out of interest, what do you get when using the following?
CASE [table].attend
WHEN NULL THEN -2
WHEN 0 THEN 0
ELSE 2
END