VFP6 Transaction problems. Re-post 
Author Message
 VFP6 Transaction problems. Re-post

I've  re-posted this as there was no response and it's probably
scrolled off by now. Any help would be much appreciated.

TIA

Chris

I discovered this one after hours of tearing my hair out. I don't
_think_
I'm doing anything wrong, but I'm open to advice/suggestions

I have a stored proc which returns a serial number. It consists of a
query
and an update, does no specific work area switching or specific table
opening and it is wrapped thus:

BEGIN TRANSACTION
query serial no table
update serial no table
END TRANSACTION
RETURN thevalue

When I call this proc from a form with a private datasession on return
the
currently selected work area is 1 (I suppose the first table opened by
the
form). This is a real problem as the
form's three tables/cursors are all in relationships and of course
selecting
work area one (the parent table) moves all the record pointers in the
child
tables.

Although I haven't checked this it also behaves as if the index orders
are
reset to the original in the datasession (I change them programmatically
in
the grandchild depending on a value in the child and reset
recordsource/control source for the relevant grid)

The BEGIN/END TRANSACTION is the sole cause of this - I have tried
moving
the stored proc into the method on the form, putting the serial no table

into the datasession, and also wrapping the whole method as a
transaction,
and only removing the BEGIN/END TRANSACTION solved my problem.

For this particular stored proc it isn't very important to have it as a
transaction, but I can see that there might be a case for it in the
future.

Any ideas anyone?

TIA



Sat, 31 Mar 2001 03:00:00 GMT  
 VFP6 Transaction problems. Re-post
Chris,

This is not specifically what you were asking, but I believe
part of your question is reference to the current work area
being changed.

In your sample you indicate that you query a table.  Is this
a SEEK or a SQL-SELECT.  If it is the SQL, this would
change the work area.

-myron kirby-
Independent Consultant

===========================

Quote:

>I've  re-posted this as there was no response and it's probably
>scrolled off by now. Any help would be much appreciated.

>TIA

>Chris

>I discovered this one after hours of tearing my hair out. I don't
>_think_
>I'm doing anything wrong, but I'm open to advice/suggestions

>I have a stored proc which returns a serial number. It consists of a
>query
>and an update, does no specific work area switching or specific table
>opening and it is wrapped thus:

>BEGIN TRANSACTION
>query serial no table
>update serial no table
>END TRANSACTION
>RETURN thevalue

>When I call this proc from a form with a private datasession on return
>the
>currently selected work area is 1 (I suppose the first table opened by
>the
>form). This is a real problem as the
>form's three tables/cursors are all in relationships and of course
>selecting
>work area one (the parent table) moves all the record pointers in the
>child
>tables.

>Although I haven't checked this it also behaves as if the index orders
>are
>reset to the original in the datasession (I change them programmatically
>in
>the grandchild depending on a value in the child and reset
>recordsource/control source for the relevant grid)

>The BEGIN/END TRANSACTION is the sole cause of this - I have tried
>moving
>the stored proc into the method on the form, putting the serial no table

>into the datasession, and also wrapping the whole method as a
>transaction,
>and only removing the BEGIN/END TRANSACTION solved my problem.

>For this particular stored proc it isn't very important to have it as a
>transaction, but I can see that there might be a case for it in the
>future.

>Any ideas anyone?

>TIA



Sat, 31 Mar 2001 03:00:00 GMT  
 VFP6 Transaction problems. Re-post
When calling functions that change your work area, use the following
code to restore the previous work area.

FUNCTION SomeFunction
lcOldselect = SELECT()   && Save Current Work Area
-
-
-
-
SELECT (lcOldselect)    && Return to Current Work Area

Charlie



Sat, 31 Mar 2001 03:00:00 GMT  
 VFP6 Transaction problems. Re-post
Myron

Both query and update are SQL, which changes work area behind the scenes -
but at least has the good grace to put you back where you started. The
BEGIN/END TRANSACTION is specifically causing this problem - I can;t find out
why so I've stopped using it.

Chris

Quote:

> Chris,

> This is not specifically what you were asking, but I believe
> part of your question is reference to the current work area
> being changed.

> In your sample you indicate that you query a table.  Is this
> a SEEK or a SQL-SELECT.  If it is the SQL, this would
> change the work area.

> -myron kirby-
> Independent Consultant

> ===========================


> >I've  re-posted this as there was no response and it's probably
> >scrolled off by now. Any help would be much appreciated.

> >TIA

> >Chris

> >I discovered this one after hours of tearing my hair out. I don't
> >_think_
> >I'm doing anything wrong, but I'm open to advice/suggestions

> >I have a stored proc which returns a serial number. It consists of a
> >query
> >and an update, does no specific work area switching or specific table
> >opening and it is wrapped thus:

> >BEGIN TRANSACTION
> >query serial no table
> >update serial no table
> >END TRANSACTION
> >RETURN thevalue

> >When I call this proc from a form with a private datasession on return
> >the
> >currently selected work area is 1 (I suppose the first table opened by
> >the
> >form). This is a real problem as the
> >form's three tables/cursors are all in relationships and of course
> >selecting
> >work area one (the parent table) moves all the record pointers in the
> >child
> >tables.

> >Although I haven't checked this it also behaves as if the index orders
> >are
> >reset to the original in the datasession (I change them programmatically
> >in
> >the grandchild depending on a value in the child and reset
> >recordsource/control source for the relevant grid)

> >The BEGIN/END TRANSACTION is the sole cause of this - I have tried
> >moving
> >the stored proc into the method on the form, putting the serial no table

> >into the datasession, and also wrapping the whole method as a
> >transaction,
> >and only removing the BEGIN/END TRANSACTION solved my problem.

> >For this particular stored proc it isn't very important to have it as a
> >transaction, but I can see that there might be a case for it in the
> >future.

> >Any ideas anyone?

> >TIA



Tue, 03 Apr 2001 03:00:00 GMT  
 VFP6 Transaction problems. Re-post

Charlie

This would work if I was changing the work area specifically but the
whole point is that BEGIN/END TRANSACTION should not behave as badly as
this IMHO. I'm  not changing the work area - FoxPro is and it should
clean up properly.

BTW The same method as you gave but maybe slightly safer to use is to
call SELECT(0) and store it to a numeric as SELECTing a blank char field
will error

Chris

Quote:

> When calling functions that change your work area, use the following
> code to restore the previous work area.

> FUNCTION SomeFunction
> lcOldselect = SELECT()   && Save Current Work Area
> -
> -
> -
> -
> SELECT (lcOldselect)    && Return to Current Work Area

> Charlie



Tue, 03 Apr 2001 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. VFP6 problem (repost)

2. REPOST: Need help with TRANSACTIONS

3. repost: Remote views and transactions

4. REPOST - Begin/End Transaction

5. VFP6 Problem after issuing END TRANSACTION

6. Repost - losing mouse pointer with VFP6+Crystal Reports preview

7. Controlling SQL Server transactions in VFP6

8. - How to implement efficient transaction logging in VFP6?

9. VFP6.0/SP3, transactions

10. Read level problem in FPW2.6 (repost)

11. Newsgroup Netiquette for Cross-posting and Multi-posting

12. VFP 6.0 Index open problem with Begin Transaction

 

 
Powered by phpBB® Forum Software