Hello Lars, I can see why the inconsistency in querying base table name is inconvenient but can also understand why is does so. I would not regard it as a bug because it is probably intended to behave like this. A bug and a compromised design are quite different although the inconvenience for developers is the same. It is however a shame it's not documented.
If we were designing the behaviour of SelectionInfo(SEL_INFO_TABLENAME) from scratch and hit on the problem of joins, how would we handle it? 1) Return nothing - useless. 2) Return the first table; A - reasonable, but not very helpful. 3) Return both tables; A,B - causes a problem in that table names are assumed singular 4) Return a fresh query table name - a cheap option but denies access to underlying table name. I assume that the argument for choosing option 4 is that a join has a non-simple relationship with it's base tables and so a detachment is made. Regards, Warren Vick Europa Technologies Ltd. http://www.europa-tech.com -----Original Message----- From: Lars V. Nielsen [mailto:[EMAIL PROTECTED] Sent: 17 October 2003 11:41 To: MapInfo-L Subject: MI-L Bug in MapBasic - SelectionInfo ? Hi list, Can anyone confirm this problem, or better yet suggest a work-around ? I'm using SelectionInfo(SEL_INFO_TABLENAME) to provide the name of the base table from which the current selection is drawn. Usually this works fine, but if the selection is a join, e.g. SELECT * FROM A, B WHERE A.ID = B.ID, it suddenly returns the query name instead, e.g. "Query1", instead of "A" !! The selection *is* made of a base table (it's not stand-alone as when one uses a GROUP BY). If I edit something in the query, the base table is changed accordingly - as it should be. And the status bar shows the correct base table name as "selected". So the connection from the query to the base table is definitely in place and working properly, it's only MB that errs. The manual only talks about joined selections giving possible problem with SEL_INFO_NROWS: >> Note: If the current selection is the result of a join of two or more tables, SelectionInfo(SEL_INFO_NROWS) returns the number of rows selected in the base table, which might not equal the number of rows in the Selection table. << Nothing at alle talks about returning a different value for SEL_INFO_TABLENAME (except blank if no selection) So I assume this is a bug. It's the same in both 6.5 and 7.0, btw. Best regards / Med venlig hilsen Lars V. Nielsen -------------------------------------------------------- Hvenegaard & Meklenborg Rugaardsvej 55, DK-5000 Odense C Denmark http://www.hvm.dk --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 8776
