>On Mar 3, 2007, at 4:59 PM, Ken Dibble wrote:
>
> >>> The KeyField *is* in the query.
> >>
> >> Yes, but not with the table.column format. You want to
> >> specify the
> >> column that pertains to the key field.
> >
> > I don't understand what you're getting at. Here's the query, broken
> > down
> > into clauses:
>
> I understand that it is in the SQL. What I'm saying is that it is
>not in the resulting dataset.
>
> If I run a query that reads "select tbl.col1, tbl.col2 as frog
>from...", the dataset I get back will look like:
>
>({"col1": "val1", "frog": "green"}, {"col1": "another", "frog":
>"croak"}, ...)
>
> This is a tuple of dictionaries, with the keys for each dict being
>the named of a *returned* column. Note that since I aliased col2 as
>'frog' in the query, my result set has keys of 'col1' and 'frog', not
>'tbl.col1' and 'tbl.col2'.
>
> You got a KeyError (that's Python, not Dabo). That means that you
>referenced a key in a dict that didn't exist. In the records above,
>referencing 'tbl.col1' would throw a KeyError, since there is no key
>with that value.
>
> > Fields clause, includes a derived field; pkid is the last (third)
> > field in
> > the list:
>
> I see that, which is why I was surprised that you still got a
>KeyError when you changed KeyField to 'pkid'. That means that you
>don't have a column named 'pkid' in your result set. That's the only
>way that Python would throw such an error.
>
> > The only table mentioned in the FROM clause is musSongs; is that
> > the one I
> > should use? It seems arbitrary given the purpose of the query--not
> > that
> > there's anything wrong with that.
>
> Yes, I guess it's arbitrary, but it won't hurt you, as long as you
>don't need to update.
>
> > But then the grid isn't going to be able
> > to display my derived field, artist, is it? Since there is no field
> > by that
> > name in musSongs?
>
> We don't care about the backend in the GUI. We're 3-tier,
>remember? ;-)
>
> As long as 'artist' exists in the dataset, it will be displayed.
>
> >> This should always be just a column name, not a
> >> table.column name.
> >
> > If you're saying it should not be in table.column format in the
> > *query*--well, if I did that in VFP I'd get an error saying
> > something like
> > "field pkid is ambiguous", since there are several references to
> > "pkid" in
> > the query. Are you saying I can put just "pkid" in the fields
> > clause of a
> > MySQL query and MySQL will know which one I want?
>
> No, you're misunderstanding the purpose of KeyField. It doesn't
> have
>anything to do with the query side of things; it has to do with the
>result set.
>
> If your query were to read "select pkid as shinola, ...", your
>KeyField should be set to 'shinola', since that's the name in the
>result set.
>
> >> KeyError: 'musRecs.pkid'
> >>
> >> This means that there was no column in the dataset with
> >> the key
> >> value of 'musRecs.pkid'.
> >
> > But there was. You can see it in the query I posted above.
>
> There was in the database, but not in the *result set*. In there,
>it's simply 'pkid'.
>
> >> You're saying that if you change the
> >> KeyField to just 'pkid', you still get an error saying that you have
> >> no key named 'pkid'? If so, then you don't have that name in your
> >> result set. I don't know why, but that's what a KeyError means.
> >
> > Yes, if I just use KeyField = "pkid" I get KeyError: 'pkid'. If I
> > don't
> > have a KeyField statement at all, I get KeyError: ' '
>
> Now this is where things get interesting. By all rights you should
>have a key in your result set (dataset; I use the two
>interchangeably) with the value of 'pkid'. The fact that you are
>getting a KeyError from Python means that you don't.
>
> Try this: after the requery(), add the line:
>
>print biz.getDataSet(rows=1)
>
>...where 'biz' should be a reference to the bizobj. This will print
>out the first record in the dataset, so that we can see exactly what
>you're getting back.
I didn't trim the above just in case you need a refresher on where we left
off yesterday.
Now, this is very weird. After updating from SVN, I ran the form this
morning, unchanged from last night, using KeyField = "pkid". I no longer
get the KeyField error at all. Instead, I get:
Traceback (most recent call last):
File "C:\Program Files\Dabo Runtime\dabo\lib\eventMixin.py", line 97, in
raiseEvent
File "ClassDesigner.py", line 1464, in onRunDesign
File "C:\Program Files\Dabo Runtime\ide\ClassDesignerFormMixin.py", line
499, in onRunDesign
File "C:\Program Files\Dabo Runtime\dabo\ui\uiwx\__init__.py", line 882,
in createForm
File "C:\Program Files\Dabo Runtime\dabo\lib\DesignerXmlConverter.py",
line 70, in classFromXml
File "c:\docume~1\kend\locals~1\temp\tmp8xokcf.py", line 107
#biz.requery()
^
SyntaxError: invalid syntax
That's right, it's throwing an error on a commented line of code that is
syntactically correct! The line is the last thing in my setupBizobj()
method, where "biz" is a valid reference to the bizobj.
If I remove that line, the form works!! Flawlessly.
But, of course, errors should not be thrown on commented code, even if that
code is wrong--which in this case, it wasn't.
I'd have to guess that something in your reversion to an earlier version of
the Class Designer not only fixed the crash bug but also changed something
in how the form code was being interpreted.
Ken
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.446 / Virus Database: 268.18.6/709 - Release Date: 3/3/2007 8:12 AM
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
