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.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
