Uli

>I won't discuss this further, but you are imputing bad intentions to Tim
>- and that's nonsense.

I imputed no bad intentions to anyone. If you think I did please point out exactly where that was.  I simply said its not sensible to rely on sales literature which is what I consider a product description on a website to be.

You are aware of what means are you?

>Probably you are annoyed by a recent discussion with Tim, but I think
>it's not a good idea to create a bad atmosphere here because of that.

I've had a number of disagreements with Tim over the years. However, I'd like you to point to a single instance of where I have allowed such disagreements to affect my posts to others.

I, as with every other human being I've ever encountered, make mistakes, and I have no problems having them pointed out to me. This is not such a case.

I have never and will never post on these newsgroups with malice or anything other than my best intentions to help.

In future I'd appreciate it if you would read and understand my posts before reacting.

Roy Lambert

Rolf,

<< http://www.elevatesoft.com/products?category=edb&type=delphibcb >>

I've fixed that text so that it's correct.

Tim Young
Elevate Software
www.elevatesoft.com

Rolf,

<< Ouch, thats not a good marketing than. They promise features they don't realy support. This brings some of a negative fealings about Elevate. >>

Really ? You think we *purposefully* put that text in there instead of it just being a mistake in wording ?

It must be nice to be able to type in pages and pages of documentation and product literature and never make a mistake.  You'll have to explain to me what it's like sometime...

<< I hope Tim will say anything about this issue. I can't realy understand, why it shouldn't wok for computetd fields at all, as it can be used in a Select statement very well. So I hope this is a oversight by Tim and he will correct this. >>

It doesn't work because computed columns are evaluated on the client-side only and they don't have access to the database catalog.  Therefore, they can't possibly refer to UDFs because they don't know that they exist.  This has been explained by me several times here on the support forums, and you can find my posts on the subject by searching the forums on "computed* function*".

Tim Young
Elevate Software
www.elevatesoft.com

In my case it shouldn't make a difference and should work also in C/S as it is a very simple UDF, just a simple SQL CASE.

CREATE FUNCTION "CheckStateText" (IN "CheckState" INTEGER)
RETURNS VARCHAR(30) COLLATE "ANSI_CI"
BEGIN
 DECLARE Result VARCHAR(30);
 CASE
    WHEN CheckState = 1 THEN
       SET Result = 'Invalid Video';
    WHEN CheckState = 2 THEN
       SET Result = 'Not Found: Unknown Error';
    WHEN CheckState = 3 THEN
       SET Result = 'OK';
    WHEN CheckState = 4 THEN
       SET Result = 'E. Process';
    WHEN CheckState = 5 THEN
       SET Result = 'Unavailable';
    WHEN CheckState = 6 THEN
       SET Result = 'Terms Violation';
    WHEN CheckState = 7 THEN
       SET Result = 'Pending Review';
    WHEN CheckState = 8 THEN
       SET Result = 'Removed';
    WHEN CheckState = 9 THEN
       SET Result = 'Violation';
    WHEN CheckState = 10 THEN
       SET Result = 'U. Removed';
    ELSE
       SET Result = 'Error ' + CAST(CheckState AS VARCHAR(20));
 END CASE;
 RETURN Result;
END
VERSION 1.00

So it is simply a funtion to give me the same result as I have defined in the computed field:

"CheckStateDesc" VARCHAR(25) COLLATE "ANSI_CI" COMPUTED ALWAYS AS CASE
  WHEN CheckState = 1 THEN
     'Invalid Video Page'
  WHEN CheckState = 2 THEN
     'Not Found: Unknown Error'
  WHEN CheckState = 3 THEN
     'OK'
  WHEN CheckState = 4 THEN
     'E. Process'
  WHEN CheckState = 5 THEN
     'Unavailable'
  WHEN CheckState = 6 THEN
     'Violation'
  WHEN CheckState = 7 THEN
     'Pending Review'
  WHEN CheckState = 8 THEN
     'Removed'
  WHEN CheckState = 9 THEN
     'Violation'
  WHEN CheckState = 10 THEN
     'U. Removed'
  ELSE
     'Error ' + CAST(CheckState AS VARCHAR(20))
END


To maintenance only one codebase for this, it would be fine to use this UDF in the computed field instead a copy of the same SQL.

Now I'm forced to update two places to make changes here and I'm unhappy bout this. Is there some other way to have only one version of this code? I don't want to do a generated field, as it would blow up my database with some unneeded addtional chars, while a computed field doens't do that, as far as I can understand it.

Rolf


I see you share my hatred of storing things twice (unless there's a very good reason of course) but based on past conversations with Tim about this issue (a lot of the times Tim has explained it are because I'd forgotten again) its not going to happen.

I sort of recall that at least one of the things I wanted to do was similar to your's and the UDF wouldn't have referenced external tables or anything nasty but unless Tim invents another language (a subset of SQL/PSM probably) to enforce the behaviour it can't be guaranteed. Relying on us programmers to never use forbidden stuff in the UDF is almost certainly not a good way to go.

Mainly using f/s rather than c/s I don't think I ever got my head round the difference between client side and server side - after all I didn't have a server

Roy Lambert

Rolf,

<< and should work also in C/S as it is a very simple UDF >>

Yes, except that it doesn't, as I've already explained.  EDB does not ship the database catalog over to the client, therefore there's no way for the client to even know that the function in question exists, let alone actually evaluating the SQL involved in the function.

Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Yes, except that it doesn't, as I've already explained. EDB does not ship the database catalog over to the client, therefore there's no way for the client to even know that the function in question exists, let alone actually evaluating the SQL involved in the function.

Just to help me get my head round it is this a c/s restriction that has to apply to f/s since you want then both the same? If so I think I've got it, if not I'm still baffled but since it hasn't killed me yet I'll live with it.

Don't spend a lot of time explaining if the answer is no since I have a sneaky suspicion it will go straight over my head

Roy

Roy,

<< Just to help me get my head round it is this a c/s restriction that has to apply to f/s since you want then both the same? If so I think I've got it, if not I'm still baffled but since it hasn't killed me yet I'll live with it. >>

It's a "there's a table/query result set cursor that has no idea about database catalogs, combine with the fact that computed columns are immediately evaluated any time any referenced columns are modified" issue.

Tim Young
Elevate Software
www.elevatesoft.com