Filter out #Error in Query (1 Viewer)

[Lightwave]

Here's something that I haven't tried to do before.

If there are a small number of field values that error out eg in expression calculations within a query.

Is there a simple way such as Not #Error?

Running a loop of a query and there are a small number of values that have calculated out as an error and I am using this field to name a pdf and then move onto the next one. Of course the routine halts when it hits the errors.

 

[plog]

The correct way is to find out what the error is and prevent it. My guess is its a divide by 0 issue. If a field(s) is in a denominator test it to make sure its not 0, if so show what you want instead of the #Error in that manner.

Bad-->
TestField: [Field1]/[Field2]

Good-->
TestField: Iif([Field2]=0, 0, [Field1]/[Field2]

 

[isladogs]

Why not use the IsError function which gives a Boolean output.

 

[Lightwave]

Thanks yes will try

 

[The_Doc_Man]

I am using this field to name a pdf and then move onto the next one

Far be it from me to say this is crazy, because I know I've gone off the deep end myself more than once, but ...

Is this "naming" thing the ONLY reason for the computation? Because if so, I think I would have to choose some other formula or even <gasp> a simple counter tacked on to a date to keep my file names straight.

Lightwave, I've seen your other posts so I believe you must have some ulterior motive for using this computation. Still, knowing you have a dodgy formula would make me want to change the darned things the second time it blew up on me. (I always assume the first time was due to my fat little fingers.)

 

[Lightwave]

We are doing a system transfer of information (there is politics involved)

Important notes need to be related to an application number for a planning system. There is no where to store these in the new system so rather than destroying them I am exporting these to files. There are enough that if I did export no one would ever be able to find the notes. Yes I could have an indexed excel file that would look up anything but I thing its easier for the user to see the application name in the filename. It so happens that the planning application number in 99% of the cases is an incremented number followed by some characters denoting application type and then a year number.

I've split these into for example 0001 FUL 2005 reversed them around and then stuck them back together so we get for example 2005FUL0001.pdf - Listed in a directory this means that someone knowing the planning application can arrange the files in az order and then open the file which relates to the application. Some applications for random reasons have different format and special characters that cannot be used when naming files.

The filenames are therefore a key with meaning. Its just the way it is