Dan Sugalski wrote:
That works too. If the information's available someone'll build what they want. Whichever way you're comfortable with. (Though given my preferences, I'd add in the hash fetch version as part of the low-level interface)
Roger:
To clarify you want:
1. You want a hash with
key value "fieldname" "fieldvalue"
done similar to
80 getnext: 81 82 .pcc_begin prototyped 83 .pcc_call fetchrow_hash 84 nextrow: 85 .result rowhash 86 .result answer 87 .pcc_end
where each call to the function will return the hash containg the next rows data.
Yep, that's it. "Here's the result handle, gimme a row of data as a hash". If you want to keep state such that it's a real iterator, that's fine. If you want to leave it so that the user of the library has to be explicit with which row they want, that's fine too.
Do you have any requests for anything else on, around or near this before I start. I should be able to ruffle something up pretty quickly.
Nope, can't think of anything yet.
Disclaimer: The lib is not very robust at the moment I am just trying to get an interface sorted out so I can then get on with coding behind it rather than chasing goal posts. I am really loking forward to all the error handling ;-)
Heh. Isn't error handling always fun? I think I need to put "exceptions" on this week's todo list.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
