|
A suggestion:
Rather than having to create columns of the correct
data type for a particular query and then update them with the particular
_expression_, create a permanent dummy column in the base tables, say MIJ as
logical data type (or something small).
Then ...
Select ... from tab1, tab2 where
tab1.mij=tab2.mij and tab1.fld1=tab2.fl1 + tab2.fld2
....
The dummy columns and _expression_ will then always
overcome the "no join specified..." problem (which appears to be an artifact of
an early design decision - performance?).
Don't index mij as the extra i/o in checking the
index is just overhead in this case.
---------------------------------------------------------------------------------
I do like MapInfo's SQL. Just found recently for
those wishing to squeeze the last bit of performance (or functionality), that an
SQL such as:
Select ... from tab1[,tab2] where .... and
cust_function(acol1,acol2,..) ....
can have cust_function as external (DLL-resident).
Also, (as is stated in the MB manual) cust_function can replace standard
functions such as cos, abs etc.
So if you had quite a bit of logic in cust_function
or prefer to write in something other than MapBasic when you have a choice,
write cust_function in c, Delphi or similar. In combination with MITAB library,
would be possible to pass rowid's and read and process objects as part of the
comparison. Using some of the ideas here (http://www.spatialprojects.com.au/spatialsql_custfns.htm ,
esp pt 8.) , it may be possible to update tab1 or tab2 (or another tab on the
fly). "may be" because I know its possible to update tab1,tab2 within MapBasic,
but not sure if an external update operation on the same table would work -
havent tested that yet. If the SQL was prefaced with a save, it most likely
would work as the MI select is only reading, so no transaction files would
exist.
---------
Dreams:
Now what would be nice is a statement to attach the MapBasic window to the
address space of one (or more!) particular (dormant) MB app with all
the declarations (and possibly code) and then write SQLs such as the one
above in MapInfo Pro.
eg. Someone writes a nice "IsParallel(l1obj,l2obj)"
function for 2 lines, which could be declared in an app and accessed from
any MI Pro SQL.
Great opportunity for commercial MB authors OR
a MapInfo community (wiki) app could receive those hidden gems accumulated
over the last 15 yrs and trapped in purpose-built apps. I suggest this would
increase the power of MapInfo SQL n-fold in a short space of time. Also, some
major new features in basic functions in MI Pro might shift all those users who
are sitting on "the last really useful update" (for me
v6.5).
Phil.
_______________________________________
|
_______________________________________________ MapInfo-L mailing list MapInfo-L@lists.directionsmag.com http://www.directionsmag.com/mailman/listinfo/mapinfo-l
