Javascript ??

[SGV_AnaLog]

Hello All,

Wishes for the day..! :)

I believe there is no any cognos inbuilt functionality to isolate any 2 digits from some 6 digit integer(for Example). Please correct me if i was wrong..

I heard from somewhere that we can do the same by using Javascript in the report.

Awaiting for the reply..!

Thanks in advance. :) :)

[CognosPaul]

Depending on your needs, JavaScript may not meet your needs. Why do you need to isolate 2 digits? Will it always be the same 2 digits for all the numbers in your dataset? Your best bet may be to use math or string functions.

Something like:
substring(cast([Integer],varchar(6)),3,2)

[SGV_AnaLog]

Thanks CognosPaul..! :)

Its a filter criteria which will work effectively. Two digits in my number indicate different modules where i  need to do work on data once i filtered out.

[CognosPaul]

The substring method should work:
substring(cast([Integer],varchar(6)),3,2) = '45'

That being said, this is a bad way of doing things. Depending on the amount of rows in your table, this can cause a bottleneck in your query. Most string expressions will implicitly force the query optimizer to do a table scan. It would be better to add a new field to your table with that specific 2 digit code. That way you could index on that field.

If you can't modify the database, add that calculated field to your framework model to make future reports and adhoc queries easier to use.

[SGV_AnaLog]

What happens when the number which i need to cast has more than 10 digits. ?
will it throw parsing error ?? :(

[CognosPaul]

Try doing something like cast([Integer],varchar(100)).

[SGV_AnaLog]

Thnks for info :)

[MFGF]

Thnks for info :)

I prefer not to cast numbers to strings if I can avoid it - it's not a very efficient process. I would use mathematical functions instead if I could

eg if you have a number 123456

and you want to get the third and fourth digits

You could use this approach:

floor([number]/100) would give you 1234
then you could use mod() on the results of this to get the last two digits

eg mod(floor([number]/100),100)

This would return 34 - no casting and no javascript :)

MF.

[SGV_AnaLog]

Kudos to you  MF :)

[bbtresoo]

I prefer not to cast numbers to strings if I can avoid it - it's not a very efficient process. I would use mathematical functions instead if I could

eg if you have a number 123456

and you want to get the third and fourth digits

You could use this approach:

floor([number]/100) would give you 1234
then you could use mod() on the results of this to get the last two digits

eg mod(floor([number]/100),100)

This would return 34 - no casting and no javascript :)

MF.

Hi MF,

What do you mean by I prefer not to cast numbers to strings if I can avoid it - it's not a very efficient process is it a matter of performance here?

[MFGF]

Hi MF,

What do you mean by I prefer not to cast numbers to strings if I can avoid it - it's not a very efficient process is it a matter of performance here?

Maybe because I'm old and still have a mindset based in the good old days where every byte and every cpu cycle was precious, I still try to use the most efficient way I can find of doing things. Casting from one data type to another has always been inefficient (ie uses memory and/or CPU not necessary if you can find a different way)

In reality it probably makes so little difference to performance you wouldn't notice on a modern server, but I'm just a picky old muppet :)

MF.

[bbtresoo]

Maybe because I'm old and still have a mindset based in the good old days where every byte and every cpu cycle was precious, I still try to use the most efficient way I can find of doing things. Casting from one data type to another has always been inefficient (ie uses memory and/or CPU not necessary if you can find a different way)

In reality it probably makes so little difference to performance you wouldn't notice on a modern server, but I'm just a picky old muppet :)

MF.

tks always good to learn from elder!!! ;) , it's always interesting to know differents ways to solve a pb.!!!

[CognosPaul]

Casting is a fairly expensive process, and The Muppet is correct that numeric expressions would be faster. Casting and string expressions are notorious for ignoring indexes and forcing table scans.  Ultimately the correct solution would be to fix the table. If you're requirements are to filter on a specific range of characters in a larger field, split that out into a separate field. You could then put an index on that field if necessary.