Filter layer with MS/SQL based attribute ? b=SMftptmlbsr0DT00M4m7daF/51hDTSm35WHy/94yZIRDphDM0FPGm2tkV1LmtdgbMd5Vk1cBJixCTDeM2f2H/VzIAA9atB3PtyMnroddAltBA7JFses2z3tneVcXv7BSmrrfwOvY116jp4A09d2p0c6uc3Z20p/gGI39T b=IWJCkvYh35

[Lars V. Nielsen (Hvenegaard)]

Hi Frank,

My point about the left join was that a failed lookup didn't remove the
feature, it just added (random/null/arbitrary) values. I was looking for it
to filter. It's not a bug as I see it, just a clarification of it's purpose.
However, I do see some random values being added, that may be a bug.

The non A-Z character I was referring to was not digits but Danish
characters (æøåÆØÅ). I.e. ascii values from the 128-255 range. They're valid
in MS/SQL, but apparently the OGR SQL parser doesn't support them.

You didn't comment on this item: does the OGR SQL Parser support views and
not just tables ? It seems to report "not found" whenever I try to enter a
view instead of a table.

About the bug reports, I just want to be sure whether it's a bug and not
(just) an absent/missing feature. If it's a bug, I'll be happy to file all
the reports you want ;-)

Best regards / Med venlig hilsen
Lars V. Nielsen
--------------------------------------------------------
Hvenegaard A/S
Rugaardsvej 55, DK-5000 Odense C
Denmark
Tel. +45 6313 5050
http://www.hvenegaard.dk
----- Original Message ----- 
From: "Frank Warmerdam" <fwarmerdam at gmail.com>
To: "Lars V. Nielsen (HVM)" <LVN at hvenegaard.dk>
Cc: <MAPSERVER-USERS at lists.umn.edu>
Sent: Wednesday, August 24, 2005 10:59 PM
Subject: Re: [UMN_MAPSERVER-USERS] Filter layer with MS/SQL based attribute
?
b=SMftptmlbsr0DT00M4m7daF/51hDTSm35WHy/94yZIRDphDM0FPGm2tkV1LmtdgbMd5Vk1cBJi
xCTDeM2f2H/VzIAA9atB3PtyMnroddAltBA7JFses2z3tneVcXv7BSmrrfwOvY116jp4A09d2p0c
6uc3Z20p/gGI39T
b=IWJCkvYh35Gy6GMN83fa/xUK0VzPZmoe75rA7guuZG/zCcEwKSk29KAdbHiVeJkTB9D2r0hlKy
MWzBPUYDh18CO4NWUJiysiT1nly92PhnVHIub/J1DV91TJkNPy2CIz95gtzKsrlUwzsMPJfVO+N6
9bpwe2ig8xRoHr9fFQqOM=


On 8/24/05, Lars V. Nielsen (HVM) <LVN at hvenegaard.dk> wrote:
> - besides, OGR always perform a LEFT JOIN (apparently adding random values
if none are found), so it doesn't filter anything anyway

Lars,

It should be leaving the extra fields NULL if the join lookup fails.
If that is not the
case, I would appreciate your filing a bug report sufficient for me to
reproduce
the problem.

> - OGR definitely doesn't like non-A-Z characters in the table and column
name, I get an SQL parse error if such are used

Generally speaking OGR does allow numbers in table names.  It should also
allow
stuff like underscores, but it may be too harsh in it's parsing logic.
 Could you
be more specific about what does not work?

I just created a shapefile called p2.shp and the following worked:

 ogrinfo -ro -sql 'select * from p2' p2.shp

> I've tried to filter my layer content with both a LAYER/FILTER or a
CLASS/EXPRESSION, but how to I test for the value NULL ?

I don't think that MapServer has a concept of NULL values for items,
though I could be wrong.  You may have to filter the items against the
empty string to simulate NULLness.

Best regards,
-- 
---------------------------------------+------------------------------------
--
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent