Tim


I thought it would be worthwhile giving you a couple of simple examples about my use of UDFs in filters. First remember I'm talking tables NOT sql. I'll happily switch to sql after you have eliminated the close and reopen (causing gashtly display "flickers") and maintaining the current record when changing an index <no g>.

1. In the UK we have several block of phone numbers:

01's
020's
02's other than 020
01's where the std code is 3 characters
01's
07's
08's
09's

each of which requires to be differently formatted on display. These are stored as strings and the way I've handled the display is to format the number before posting. For searching (eg some's called, I pick up their number from 1471 - caller identity or they've quoted it) and set up a filter. With a user defined function I can strip out all the spaces and not have to bother about formatting. I can't easily format the number because on many occasions all I can get from the mumble is the first, last or middle characters.

Please don't recommend a separate field - the frequency of use doesn't justify it.

2. Another UDF scans documents linked to an individual/company. Sometimes this is combined with other criteria to reduce the number of cv's (resumes to our US brethren) I have to look through. eg Quality Manager who is a Master Black Belt (6 sigma qualification not martial arts).  In this case it ended up reading and scanning c100 cv's for me. Again its not to frequent but very useful (I have someone who will hopefully be resigning on Monday). This one I can't see an alternative for at all.

Roy Lambert

Roy,

<< I'm beginning to dislike ElevateDB again.  This is the second very useful
item that's disappeared. Are there any more nasty surprises? Losing the
ability to do text searches on unindexed fields was bad enough - I can write
my own routine BUT now I find I can't use it in a filter. That seriously
screws one major app and two minor ones in terms of conversion. >>

I spoke too soon on this - I double-checked and you can UDFs safely in
filters.  There was an original issue a couple of months ago that prevented
this, but it's since been fixed.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< I thought it would be worthwhile giving you a couple of simple examples
about my use of UDFs in filters. First remember I'm talking tables NOT sql.
I'll happily switch to sql after you have eliminated the close and reopen
(causing gashtly display "flickers") >>

1.03 will do refreshes without requiring a close/re-open.

<< and maintaining the current record when changing an index <no g>.>>

What indexes ?  The TEDBQuery component doesn't surface any index
functionality.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


OK you get another chance

Roy Lambert

ps did you make a mistake about COLLATE and non-indexed columns as well <vbg>

Tim

>1.03 will do refreshes without requiring a close/re-open.

Does that include with a change to the order by clause?

><< and maintaining the current record when changing an index <no g>.>>
>
>What indexes ? The TEDBQuery component doesn't surface any index
>functionality.

OK how about maintaining the current record when changing the order by clause?

Roy Lambert

Roy,

<< Does that include with a change to the order by clause? >>

No, of course not.  Any time you change the actual SQL the result cursor
must be closed.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< ps did you make a mistake about COLLATE and non-indexed columns as well
<vbg> >>

Refresh my memory - what is the issue with COLLATE and non-indexed columns ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< Does that include with a change to the order by clause? >>
>
>No, of course not. Any time you change the actual SQL the result cursor
>must be closed.

Thought so. Tables still rule <VBG>

Roy Lambert

Tim


Oh good. Your memory's going as well

Roy Lambert

Tim


Woops - its only my memory (or my typing ability) I should have typed CONTAINS not COLLATE then you would have understood the joke.

Roy Lambert