Please free me from this - I'll PAY

[Bastiaan Olij]

Hi Das,

Everything has a scope in OO :) Yes a task variable makes that instance
available everywhere, but it doesn't mean that object can access
everything else.

What you are doing works fine, I was simply explaining why using the
statement block works v.s. why a character variable didn't. If this
works for you right now, go for it. Revisit it some time later when you
understand more and you can always clean it up.

I too have my session object as a task variable, for me it is a global
resource and it saves a lot of headaches. I also have a global statement
object but I use that more for incidentals, and I use it less and less.
With table classes I rely on the build in statement object that gets
created after you assign your session object to your table class (which
I do in my tBaseSQL.$construct method so I don't have to worry about it).

I don't know why the fetch into doesn't work but replace it by:
Do tstaobj.$fetch(lvList, kFetchAll)

lvList should be a local list variable that you do not define. just
leave it empty. $fetch should add the needed columns and load the result
set into that list. Then you should be able to do:
calculate $cinst.cust_id as lvList.1.C1

For some reason I trust $fetch into a list more then fetching into rows
or directly into variables. No other reason then it consistently working
for me.

Finally:
do tstaobj.$prepare()
do tstaobj.$execute()

Does exactly the same thing as:
do tstaobj.$execdirect()

The split into prepare and execute becomes useful if you want to insert
a whole list of records, you prepare once, then execute on every line of
your list. It can be faster. I rarely use it other then for dedicated
import processes where the speed difference starts being measurable.

Cheers,

Bas


On 31/1/18 10:07 am, Das Goravani wrote:
>
>> On Jan 30, 2018, at 1:30 PM, Bastiaan Olij <bastiaan at basenlily.me> wrote:
>>
>> I think you're biggest issue with what you've been doing so far is using
>> a separate statement object because it screws up your scope. This
>> approach works because begin statement/end statement does one thing
>> different then calculating a string and sending that to $prepare or
>> $execdirect. Statement blocks retains the scope of where the "sta:"
>> command is executed.
>>
>> So seeing your code runs in a method of your table class, ergo runs
>> within the scope of your list, $cinst points to the row you're trying to
>> insert into your database and you're query works.
>>
>> When you do:
>> Calculate lvSQL as '<your insert statement goes here>'
>> Do tstaobj.$prepare(lvSQL)
>> The SQL is simply text being send to $prepare. It is now parsed when
>> inside of tstaobj and $cinst now points to tstaobj, your row has now
>> fallen outside of the scope of the executing method and you're query
>> can't be parsed, hense your error.
> Bastiaan,
>
> This is getting crazy.  The following code now works inside a table: 
>
> Begin statement
> Sta: {INSERT INTO customers ("cust_id","cust_firstname",”cust_lastname”..."cust_bizname”) 
> VALUES (nextval('seq_cust_id'),@[$cinst.cust_firstname]...@[$cinst.cust_bizname])  
> RETURNING ('cust_id')}
> End statement
> Do tstaobj.$prepare() Returns lReturnFlag
> Do tstaobj.$execute() Returns lReturnFlag
>
> The above Statement Object is a Task variable which I used to assign into the row which is the table. 
>
> The above code inserts a record with the nextval value put in correctly. 
>
> I am now down to “How to fetch that value back” for display on the screen. 
>
> I thought statement objects were universal as the manual implies. Because the manual suggests using Task variables as your session and statement objects so that you’ll have easy access to them everywhere. Sounded good to me. 
>
> It sounds like you are saying that statement objects have scope, or can cause other things to fall out of scope. 
>
> I am almost afraid to try your method, because I’m so burnt out on this.  
>
> Someone sent me a way to fetch my value but it’s not working. 
>
> It looks like this: 
>
> Do tstaobj.$fetchinto($cinst.cust_id) Returns lReturnFlag
>
> If it worked I’d be on my way.  I just want to add the sequence (done) and know what it is back in my window. That’s all. 
>
> Any complex things I can avoid I would rather avoid. 
>
> Are you sure I can’t use my universal statement object?  As the manual suggests?  
>
>
>
>
>
>
>
>
>
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
> Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com 


-- 
Kindest Regards,

Bastiaan Olij
e-mail: bastiaan at basenlily.me
web: http://www.basenlily.me
Skype: Mux213
http://www.linkedin.com/in/bastiaanolij