Search results for query: *

It is bad manners to get a solution from a different forum and then post it here as yours. You should also probably acknowledge the people who helped you on the other forum.

You would need to post the logic as to why the data should join like that. i.e. why would 189 be associated with 100 and not 200?

Does Dagon's response more fully answer your question?

Short answer? You are going to need IT to maintain this.

I would very, very strongly advise you to endeavour to get the datatype of that column changed to a date. There is never a good reason to have a date stored as text in a database such as Oracle.

Maybe I'm missing something, but surely a simple analytic will do the job: WITH T AS ( SELECT 'user a' usr, TO_DATE('9:00','HH:MI') tm, 'logged in' stat FROM DUAL UNION ALL SELECT 'user a', TO_DATE('9:01','HH:MI'), 'logged in' FROM DUAL UNION ALL SELECT 'user a', TO_DATE('9:02','HH:MI')...

You are entitled to your opinion of course.

VB is a completely innappropriate tool for doing this. Use External Tables.

1. I would doubt this (in either case of the code) as I'm pretty sure that BO won't accept aliasing in its dynamically created sql. 2. SYSDATE is a date, why would you use a to_date on it? Makes no sense whatsoever. although, as Santa points out, your main issue seems to be with your brackets.

Only If those values are now text i.e. there was most likely a to_char performed on the value within the definition of the view. If they are not text, then they do not have trailing zeros. Jim

Serves me right for not reading fully the question. Answer number 1 is that the 'numbers' must be stored/passed as strings. storing/passing them as numbers will normalise the number and instantly become useless for anything with trailing zeros. after that, a little bit of arithmetic (an...

Maybe a quick demo: SQL> select to_char(7.5,'0') 2 from dual; TO -- 8 SQL> ed Wrote file afiedt.buf 1 select to_char(7.5,0) 2* from dual SQL> / TO -- 8 SQL> ed Wrote file afiedt.buf 1 select to_char(7.5,'00') 2* from dual SQL> / TO_ --- 08 SQL> ed Wrote file afiedt.buf...

Why not just SELECT DISTINCT b.amount_code_description, to_char(sum(CASE WHEN b.year = '2005' THEN to_char(b.ytd_amount, '9999999999.99') ELSE...

NEVER modify the contents of your redo log files.

Maybe this'll help: DROP TABLE foo; CREATE TABLE foo (eg NUMBER, x NUMBER, y NUMBER, z NUMBER); --Example 1 DECLARE l_x NUMBER := 1; l_y NUMBER := 2; l_z NUMBER := 3; l_str VARCHAR2(32767); err_line EXCEPTION; PRAGMA exception_init(err_line, -01008); BEGIN BEGIN EXECUTE...

@Dagon, true, but the op specifically asked if it could be done without looking at the num_rows column.

Well, if that table has a primary key on it, you might consider counting on that instead. Oh, and if anyone suggests count(1) .... well, just don't :)

All of which would have been clear if the terrible when others had either not been used, or been used correctly

define what you mean by last month. Last 31 days, between now and this day last month, from the first day to the last day of last month ....

The first thing to doi is get rid of what is one of the worst pieces og coding that you can write i.e.: EXCEPTION WHEN others THEN CASE i_position WHEN 1 THEN RETURN 1; WHEN 2 THEN RETURN 2; ELSE RETURN 10; END CASE; Then...