Null check on decimal crystal reports using CDBL({value}) - vb.net

I am using a decimal value in a formula which gives error when there is no data.
I tried using CDBL({value}) i.e. create a formula for value=CDBL({value}) .
The use {#value} in the formula. This used to take care of null values. But now keep getting error IF NOT ISNULL({#Value}) THEN ' A number, or currency amount is required here. Details: errorKind
Any suggestions on how to fix this please

I will try to answer this and see if I get any sort of indication that it worked.. maybe even a correct answer indication :)
You cant have mixed field types returned in Crystal. If one part of the IF statement returns a numeric type then the rest has to be numeric type. If you post your entire formula I (or someone else who is willing to give up valuable time) can show you how it needs to look.

Related

SQL query that prevents Excel from converting long integer to scientific notation

So it's been a long time since I've done anything fancy with SQL, so I'm going to do my best to explain. Please be nice, I'm trying my best here.
Basically, I'm pulling information from a database in Snowflake and putting it into a new XML file, and that data is input exactly as-written into a form email.
One of the values is an ID number that's 14 characters long (example: 12345678912345), which is stored in the database as an integer (or so I'm told), but Excel keeps automatically converting it into scientific notation. Since it's an ID number, it needs to look like an ID number, not scientific notation.
Right now, my query just selects & inputs the regular ol' value, and then we manually change it in the Excel sheet. Like literally just SELECT ID_Number from TheThing
One thing I thought might work is:
SELECT CAST(ID_Number as bigint) as ID_Number
... But it doesn't work. Most other solutions I've found don't seem to address my specific scenario of unwanted integer-to-string conversion & I'm distraught.
I'm just an intern and this might have a very obvious answer, but my fellow interns have given up on it and I need to find the answer for my own sanity. It's been a minute since I did anything fancy with SQL so please be nice to me and sorry if this is a dumb question.
In Snowflake, BIGINT and INT(EGER) are the same thing, what you want is VARCHAR. As Ross mentioned in his comment, this is likely just a formatting issue within Excel. In Excel any value can be cast as a string by including a single quote ' at the beginning of the value, or by using the Text-to-Column feature.
If you wanted to try to format it out of Snowflake as a string, casting it might not do the trick unless you include some kind of additional string character.
To get this type of formatting out of Snowflake, you can try:
SELECT '\'' || CAST(ID_Number AS VARCHAR) as ID_Number;

Alteryx Unknown Variable

i have a problem with alteryx. The problem is that although I have Score_Yes column in the input of Score, I get unknown variable error. Could you help me?
The Summary tool will only output the grouping variables and aggregate variables selected in its configuration. You probably lost [Score_Yes] at that stage.
Please try below option
1. identify from which table Score_yes is flowing, then convert the value of Score_yes to numeric

query where '0'

I need to query a varchar field in sql for 0's.
when I query where field = '0' i get the resulting error message.
Conversion failed when converting the varchar value 'N' to data type int.
I'm having trouble figuring out where the issue is coming from. My Googling is failing me on this one, could someone point me in the right direction?
EDIT:
Thanks for the help on this one guys, so there were 'N's in the data just very few of them so they weren't showing up in my top 100 query until I limited the search results further.
Apparently sql didn't have any issue comparing ints to varchar(1) so long as they were ints as well. I didn't even realize I was using an int in the where farther up in my query.
Oh and sorry for not sharing my query, it was long and complicated I was trying to share what I thought was the relevant from it. I'll write a simplified query in future questions.
Anyone know how to mark this as solved?
If your field is a varchar(), then this expression:
where field = '0'
cannot return a type conversion error.
This version can:
where field = 0
It would return an error if field has the value of 'N'. I am guessing that is the situation.
Otherwise, you have another expression in your code causing the problem by doing conversions from strings to numbers.

LONG column value

I am having an issue with attempting to import data from an excel csv file. I am using SQL Developer 4.1. My problem is I keep getting an error of:
ORA-01461: can bind a LONG value only for insert into a LONG column
despite the fact that I am not using a LONG column. That is not even an option for me to use. I am only using varchar2, number, and date. Can somebody assist in explaining what the LONG thing is, and how I can get around it? And yes, I am aware of how stupid this sounds.
I think the problem is the other way around, i.e. you are trying to enter a number into the number column that is too high. The Datatype is defined here https://docs.oracle.com/cd/B28359_01/server.111/b28318/datatype.htm#CNCPT1832

SQL Server Reporting Services Rounding after a set number of decimal places

I need to do some very precise reporting in SQL Server Reporting Services. I'm actually attempting to show 13 decimal places. The odd part is even when I format the field C13, Reporting Services seems to round after an arbitrary number of total digits rather than anything to do with the format string.
For example if I have:
1000.01234567890123
What I end up with is:
1000.0123456789000
If on the other hand I have:
10.01234567890123
What I end up with is:
10.01234567890100
So it appears that I only end up with 15 actual digits from my source number. Has anyone seen this before, or know how to resolve it?
It sounds to me like you are using the Float datatype. Instead, I would suggest you use the decimal data type instead. You'll probably want to use something like Decimal(20, 14). You'll still need to be very careful about the math you perform because SQL Server will modify the resulting data type when you perform math on decimals.
Actually, I found the problem was Microsoft's Double.ToString() method. I had to use a "G13" as a formatting string to get all of the decimal places. Go figure.