I have developed an RIA for a company's external sales force where they can view relevant information regarding thier customers before a site visit.
The data resides in SQL and is set to default to zero if any of the values are NULL. For example
(SELECT ISNULL(SUM(ISNULL( FMS2.NotDueLCY, 0)), 0) AS NotDueLCY
FROM dbo.FLEX_BalanceOverdue AS FMS2
WHERE
FMS2.ShipToCode LIKE #ShipToCode
AND
FMS2.Customer LIKE #Customer
AND
FMS2.SalesPersonCode LIKE #SalesPerson) AS NotDueLCY
If this query is Executed the data looks correct. This query is in a Stroed Procedure. I then use coldfusion to inoke these SP's
If it is executed using CF the Zero Values appear in the browser window as 0E-20 and susequently this data also appears in Flex as 0E-20
I am a bit stumped as to what is causing this. If any of you have some ideas I would be most grateful
BD :)
Managed to fix this. I had to handle the fact that a NaN was hitting the Flex app when the value of data was a zero and after some thorough checking only a zero. So once that was apparent I applied a label function to the data grid displaying the data. Telling it if a NaN was in the data set display a Zero. Not solved the root of the issue but a tidy work around
It possibly something to do with the way its coming out of your Stored Procedure. If you're using cfstoredprocedure to call your SP you could use cfprocparam to ensure that it is returning the values as the expected datatype.
If you're using CFQuery to call your SP, you'll probably need to CAST your columns on the SP side to make sure that the result is returned as the correct datatype.
Related
I am using SSRS Report Builder 3.0 and I have put together a report, part of which uses a query that pulls in data and separates it into different summary rows using the NTILE() function in SQL. That's all working fine and dandy, but boss now wants me to add a parameter to decide whether the report should pull quartiles, quintiles, deciles, etc. and so I figured I would just create a parameter to pass an integer to the NTILE(#ntiles) function, and that would be a piece of cake.
Problem is, I've created my parameter, it is an INT and passes a value like (2,3,4,5,6,10) and linked it to my query in Report Builder, but when I save the query with NTILE(#ntiles) (I named my parameter #ntiles) it throws an error:
The function 'ntile' takes only a positive int or bigint expression as its input.
The funny thing is, the report will still run, and correctly as if the parameter works, but I have no idea why it's throwing this error and pretending like it's not going to work. Google didn't really turn anything up on this issue; is it a bug with Report Builder 3.0 or am I doing something wrong? How can I make the error go away? Thanks.
EDIT: Trying NTILE(CAST(#ntiles as INT)) threw the same error, and then broke the query so that the report would not run. Weirdly enough, just changing it back to NTILE(#ntiles) left it still broken; workaround was to change it to a real INT like NTILE(4), reload the query, then go back and change it to NTILE(#ntiles). It still throws the error when you save it, but it does not prevent the report from running with that workaround.
Got me flummoxed!: I have a function that I call...
SELECT UNIT
FROM POWER_ASSETS.[dbo].[returnbaseload] ('03-12-2015','EUR')
WHERE C_TIC = 'LSE:SOE'
The function "returnbaseload" queries values from a view and does some calcs with the values. Simple. It returns 29 rows.
If I open it up in a new SQL query tab, copy n paste... it returns 533 rows.
If I copy and paste from new tab back to old tab.... 29 rows.
Any ideas? Got me beat.
P.S have also tried putting
Use POWER_ASSETS
GO
just in case there was a duplicate table accidentally created somewhere in the master...
I am worried because I am calling the function eventually from a vb program and am getting the wrong amount of rows from the sql query in vb. That's what got me investigating... the right amount of rows was from the new tab, 533 rows.
There's no way a deterministic select fetches different result sets when using the same parameters. Period.
As comments indicates you must being overloking or missing something.
1 - Be sure both panes are using the same.
[SERVER/INSTANCE].[DATABASE].[SCHEMMA].[TABLE]
it's by far the most common scenario.
It also is valid for function/SP calls. Be sure you are calling the same object and not a different version of it.
2 - Be sure both are using the same user/privileges.
Maybe you are using different connection parameters
.
3 - Be sure there's no implicit convertion messing with your query.
You are using some sort of varchar to date convertion here. Be sure you got the same settings (collation, copy from a unicode to a UTF-8 archive, etc.) in both tabs. Also you can try to query the table using some sort of GETDATE() function instead of dealing with that varchar literal.
4 - Be sure your data is not changing while you query it.
Stop the server and put it in single user. Maybe your data is just being updated.
5 - Be sure there are not any random function in the query.
Sometimes we got funny BL and someone unintented put some rand logic in it.
6 - Be sure you are not just drunk or tired.
Once I and a friend where working for like +20hrs no stop. He got angry with a buggy "dot" in the screen. Turned ou it was a actual bug (a fly) and also tried to get rid of it with the mouse pointer.
Calm down and call a friend to get a look on it.
I was happy to find you can use an Excel-like YEARFRAC function in MS SQL server (http://technet.microsoft.com/en-us/library/ee634405.aspx), but for some reason I get an error that states:
'yearfrac' is not a recognized built-in function name
when I try to run my query. Here is my code:
SELECT CUSTOMER_ID, PRODUCT_SKU, SUB_START_DATE, SUB_EXP_DATE,
YEARFRAC(sub_start_date, sub_exp_date) AS START_TO_END FROM ...
For the record, I have double-checked the dates are in proper datetime format, and I tried both using no basis (as shown above), and using the available 1-4 bases. I also tried removing the column alias (START_TO_END). None of these worked. Any ideas?
No, that is in Analysis Services (DAX specifically), not in T-SQL. The header on the page does not make it clear which section of the documentation you're in, but look at the table of contents on the left...
Sorry the screen shot is double size, it's because of my Retina screen giving 144dpi instead of 72dpi.
Anyway, you should be able to replicate this functionality with your own UDF or, if you always calculate a specific way, it might even be simple enough to do inline. A calendar table may help.
We have recently had to do some work with an OpenEdge database that a third party product uses, and today (after much hair-pulling), we finally identified why a view was returning no results.
This view in question combines about 100 separate tables, and is then queried against (we have limited rights to this database). One of the fields returned by this view is a hard-coded string literal, along the lines of
'John Smith' AS TheName
We were having difficulty running queries that included this string, which we were trying to RTrim (the view returned a lot of trailing spaces) and then concatenate with another field.
However, if we used RTrim on this field then, instead of returning an error message, or a null or something like that, the row simply wasn't returned. We weren't trying to use it in a WHERE clause or JOIN, this was simply part of the SELECT ... FROM VIEWNAME. After reviewing the view, it seemed that the view had erroneously detected the length of the string as 9 characters (no length was specified in the definition), and RTrim just didn't work.
Now, I could understand why this might lead to an error message, or a NULL value in the SELECT, but why would the row simply not be returned at all? This doesn't seem like good SQL behaviour and I've never seen it happen with any other RDBMS.
Other info : we're test querying via ODBC and WinSQL, with a view to this being included in an existing ASP.NET app. We don't have access to the backend except via this, although we do have rights to create views.
Update : As a freaky follow-up, we have now discovered that if we attempt to query this view without any WHERE clause, no records are returned. This may have the same cause.
This sounds like it could be related to the SQL-WIDTH within the progress database. One problem with Progress is that if the content of the field exceeds the SQL-WIDTH then you will get strange SQL behaviour (sometimes the driver might fail, other times you get no results).
To identify this you need to use the dbtool command to check for SQL-WIDTH's that may be exceeded.
Make sure you don't have blanks. Trimming doesn't remove blanks only spaces. Blanks are also not nulls. There is a difference in the character set while it is not visibly different in your editor.
I have run into this with a few databases, DBII, Oracle, PostGreSQL. Check the character set of your editor and try viewing the tables, you might see nothing or you might see big rectangles.
That sounds like very strange behavior. Just code around it, do the trim and/or string manipulation in the application and go on your way.
I am using application builder and setting up select boxes to populate a query that spits out into a report below, I'm having a problem with one populating though, and I can't immediatly see why;
Here's how I'm referencing;
AND CINEMA.LOCATION = :pticketstown
this works fine and pulls in the choice from the select box which is popluated from a query on the cinema table, however when I try and do the same thing for another table, try and pull in a film title from a select box choice - it doesnt seem to work, the rport says no output.
Im setting up the select box the same way, and its pulling in the films, but when as soon as I reference it in the sql report, the ouptut is empty.
FILM.FILM_TITLE = :pfilm
Has nayone any thoughts on why it would fail on something that uses the same method ? is it a case that the value isn't bieng passed across? I'm a little stumped if that's the case as I set it up the same way as the working one.
Thanks for looking
I assume from the sound of it you are using application express? Have you turned on debugging to see exactly what is being passed? It might be encoding the spaces or something.
It seems strange that the two, seemingly similar queries would behave differently. Do you have access to the actual sql produced? If so, i would try running that against your db direct through the command line or sql developer if you have it.