Hi Lars, I think I could counter arguments 1 to 4 to varying degrees, but I'm surprised by 5 and for this reason concede that this does indeed sounds like a bug in MB. On the subject of bugs, look out for my next post for a beauty!
Regards, Warren Vick Europa Technologies Ltd. http://www.europa-tech.com -----Original Message----- From: Lars V. Nielsen [mailto:[EMAIL PROTECTED] Sent: 17 October 2003 12:30 To: [EMAIL PROTECTED] Cc: 'MapInfo-L' Subject: Re: MI-L Bug in MapBasic - SelectionInfo ? Hi Warren, Please think it over a second time. 5 fast arguments for it being a bug: 1. The SEL_INFO_NROWS return the number of selected rows in the base table, not in the selection itself (see queote from manual). It would be very incosistent to require that SEL_INFO_TABLENAME returns anything but the name of the table in which the records are selected. 2. Every query has a unique name of it's own. Either named in the SELECT statement or auto-generated as "Query#". This is always returned by SelectionInfo(SEL_INFO_SELNAME), so there's no reason why this should supersede the other return value. 3. A joined selection in MapInfo *always* attaches itself to a single base table (unless it was created with GROUP BY), usually the first mappable table. So there's nothing wrong with an assumption of a 1:1 relationship from query to base table. Remember that a selection isn't a real table by itself (it's only made accessable as such as a convinience for the user/programmer), it basically just a list of record id's. 4. It works as expected in cases of selections on single tables. 5. AND the cruncher: it works exactly as I want it to do in the Pro GUI, it's the MB implementation that deviates. Best regards / Med venlig hilsen Lars V. Nielsen -------------------------------------------------------- Hvenegaard & Meklenborg Rugaardsvej 55, DK-5000 Odense C Denmark http://www.hvm.dk ----- Original Message ----- From: "Warren Vick, Europa Technologies Ltd." <[EMAIL PROTECTED]> To: "'Lars V. Nielsen'" <[EMAIL PROTECTED]>; "'MapInfo-L'" <[EMAIL PROTECTED]> Sent: Friday, October 17, 2003 1:17 PM Subject: RE: MI-L Bug in MapBasic - SelectionInfo ? > 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: 8780
