PokerTracker

Hi,

i build a column which collects the hole cards of villain (in case of a showdown) as a string.
E.g.: AKo2296oK3s...
Now i want to use this column for creating a stat which checks if for a certain hand and gives back a string.
if((strpos(str_hands, '22') > 0), '22', '__')
This one works fine - i get '22' back in case '22' is in the column str_hands, otherwise i get '__' back.
Now i am wondering if i could check within one stat more than one hand - '22', 'AKo'
But this doesn't work:
if((strpos(str_hands, '22') > 0), '22', '__') || if((strpos(str_hands, 'AKo') > 0), 'AKo', '__')
same with this one:
substr(if((strpos(str_hands, '22') > 0), '22', '__'), 01) || substr(if((strpos(str_hands, 'AKo') > 0), 'AKo', '__'), 01)

Is it simply not possible or is there just a minor mistake i am doing due to my lack of programming skills?

Thanks for your help!
miljön

Stat editor can't understand postgres functions like ||
You have to do the merge in a column.

The other way to do it is with "format".
format( '{1}{2}', if(...), if(...) )
You can use as many {x} values as you like, just make sure each has a matching piece of data comma separated after it.

I brought up this issue some month ago...
Why PT4 isn't recognizing std postgresql functions?

Works!

Thanks a lot for your help guys

4StarGen: This is a known bug due to the comma in our parser - it's not that PT4 isn't "recognizing" the SQL it's that the parser misinterprets the comma and sends a malformed string.

Is it possible to put in a new line within the format( '{1}{2}', if(...), if(...) ) expression?
For example i want to have {1} in one line and {2} in the next one...

miljön wrote:Is it possible to put in a new line within the format( '{1}{2}', if(...), if(...) ) expression?
For example i want to have {1} in one line and {2} in the next one...

No, I've asked before you... you have to build 2 stats and then place them in 2 different lines

Okay already thought so... Thanks for your help!

kraada wrote:4StarGen: This is a known bug due to the comma in our parser - it's not that PT4 isn't "recognizing" the SQL it's that the parser misinterprets the comma and sends a malformed string.

ty, I didn't know that