Subelement Not Found

[Steve Workings]

Geez, another oddity and I can't get 'round it. Has anyone run into this?:

Got a bunch of code that's typical:

t = table.open("mytable")
t.dothis
t.dothat
.....
ExistKey = t.order_id

When the script runs, it works just fine until it hits the t.order_id and pops an error message that t.order_id subelement not found. The field exists, it's spelled correctly etc. etc. Another odd point about this is that sometimes (often) it doesn't show up in the autocomplete list when entering Xbasic code to refer to it.

[Scott Emerick]

Hey Steve,

I have had the same stuff happen to me, but it was usually something silly like closing the table too soon or mis-spelling, ect. ...

Also, if I remember, I got that error once when the data types were different.

Anyway, go take a walk or something and I bet you find it when you come back.

See you in June.

Scott

[Steve Workings]

Anyway, go take a walk or something and I bet you find it when you come back.

Took a walk yesterday. Slept on it last night. Tried more today. Still no joy.

[Tom Cone Jr]

Steve,

I wonder if the field name is being interpreted as a reserved word somehow? Do you get the same error if the fieldname is changed ?

-- tom

[Steve Workings]

I'd have to do a fair amount of re-writing upstream to try this. I don't think this is the issue as I can write other scripts that use the field just fine. This, from interactive just now:

t = table.open("internet_orders")
?t.ORDER_ID
= "650        "

t.fetch_next()
?t.ORDER_ID
= "651        "

I dunno why the original problem scirpt (600 lines long so rewriting is out) doesn't "see" the field when I'm picking sublements of the pointer or why it otherwise seems to see the all the other subelements just fine.

I tried saving the script as another script thinking a bit of corruption. No difference.

I've deleted and re-written that portion of the script. No difference.

I've tried other tacts to use the value of the field but no matter how I reference it, I get the error.

[Scott Emerick]

I think Tom meant ExistKey is being interpreted as a reserved word somehow.

What happens when you debug it? Do you get a value for t.ORDER_ID before the line ExistKey = t.order_id?

That might help tell you where your problem is.

[Steve Workings]

Tried this before the offending line of code:

ui_msg_box("tOrders.order_ID", tOrders.order_id)

tOrders.order_id subelement not found

It's not the variable -- it's the reference to the field.

[Scott Emerick]

Steve,

Was that a typo or something?

You went from t.order_id to torders.order_id

Is your table pointer t or torders?

[Steve Workings]

The example I gave was from Interactive. The "real" code uses tOrders. And, just in case it gets you wondering, here's tOrders as the pointer in Interactive:

tOrders = table.open("internet_orders")
?tOrders.ORDER_ID
= "628        "

tOrders.fetch_next()
?tOrders.ORDER_ID
= "631        "

And, in a brand new script, this worked as expected:

torders = table.open("internet_orders")
ui_msg_box("", torders.Order_id)
torders.fetch_next()
ui_msg_box("", torders.order_id)
tOrders.close()

Finally, here's more of the existing code:

tOrders = table.open("internet_orders", file_rw_shared)
query.filter = "swept = {}"
query.order = "order_id"
ndx = tOrders.query_create()
count = ndx.records_get()
tOrders.fetch_first()
i = 1

while .not. tOrders.fetch_eof()

' Existing Order?
ExistKey = tOrders.Order_id   <<<-- error occurs here

[Tom Cone Jr]

And ExistKey is declared how? Is it still in scope when the offending line is reached?

-- tom

[Steve Workings]

And ExistKey is declared how? Is it still in scope when the offending line is reached?

-- tom

Currently dimmed implicitly. I've tried dimming it explicitly but no difference. And see my response to Scott below -- even when I try to reference the field with some other function, such as ui_msg_box() I get the error.

[Scott Emerick]

Hummmm ... here's a shot in the dark, but I have seen this happen too.

See what happens if you change your query.order to something other then order_id.

Like I said, it's a shot in the dark, but who knows

[Tom Cone Jr]

Steve, and remember to set the query.options value explicitly. You may be picking up trash from earlier testing...

-- tom

[Steve Workings]

Changing the query.order had no effect.

Specifying the query.options had no effect.

7 hrs on this so far plus you guys' time. Dunno, dunno.

....bit later...:

Just got weirder:

I put a reference to a different field in a ui_msg_box() just before the offending line:

ui_msg_box("", tOrders.Product_id)

Got the subelement not found, even though it's a different field.

[Tom Cone Jr]

Steve, since we can't see your script (and don't really really want to), we're guessing and guessing. Here are some more ideas. The errors you're seeing could be caused by the pointer to the table ("tOrders") being trashed or released by some other part of your script, or by a timing issue which prevents the script from accessing the table cause it's still "in use" when this line of the script is executed. If it were me, I'd insert a flock of xbasic_wait_for_idle() statements every where disk activity is occurring. I'd also make certain that I'm not using the same pointer name for different purposes elsewhere in my script.

-- tom