Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Data disappears even though TableUpdate() returns .T.

Status
Not open for further replies.

Puebles

Programmer
Feb 3, 2016
14
US
Hello,

This is my first time dealing with importing remote data via a view into FoxPro. This can be very useful for me if I can get it to work. However, I am running into a problem. The status bar shows the records appear in the table. The TableUpdate() returns .T. triggering a message that the update succeeded (for testing). However, when I attempt any action involving the table, browse, Do While loop, or refresh grid, the status bar updates to zero records and no records are available. viewlocalrequestqueue is a remote view of a table on an Oracle server.

Form Init
USE FoxLocalRequests.dbf ALIAS FoxLocalRequests exclusive
=cursorsetprop("buffering",5,"FoxLocalRequests")
SET MULTILOCKS ON

Timer
Select * From viewlocalrequestqueue Into TABLE FoxLocalRequests
Select FoxLocalRequests
=TABLEUPDATE(1,.T.,'FoxLocalRequests','myArray')
IF TABLEUPDATE()
=MESSAGEBOX("Table update succeeded.")
ELSE
=MESSAGEBOX("Table update failed.")
Endif
browse

To add to my confusion, if I run the following in the Command window:

Select * From viewlocalrequestqueue Into TABLE FoxLocalRequests
BROWSE

the records are there. I also tried this by using an array as an intermediary step and received the same results.
 
A view creates a workarea. You don't query a view INTO TABLE. No Go.

Just USE remoteview ALIAS somename, if you really want to give it another name. The data is persisted (permanently stored) in the remote database, NOT in a local DBF file, there should be no local DBF file anyway, you work in the view cursor, that IS your local VFP DBF. Most of the time not put on hdd, as the data already is stored in Oracle, just loaded into a cursor in RAM.

Also, DON'T do two TABLEUPDATEs(), the first already is the one acting and returning a success/failure value.
And since you want to use the cErrorArray parameter, look into the help once more:
vfp help said:
cErrorArray
Specifies the name of an array created[highlight #FCE94F] when nRows = 2[/highlight] and changes to a record cannot be committed.
So, this only works with the first parameter 2, not 1!

Overall, you have to read more attentively, you mixed things not intended that way at all.

In the mode you want to use (nRows=2), you always get a direct .T. from the TableUpdate() function, but you have to check the array! If there is a general error about the update the first element of the array will be -1, that's also described in the VFP help. If there is no problem at all, the array is empty and if there are problems the array elements are row numbers of uncommitted rows.

So this will not give detail information about the reasons why the rows did not submit, if you thought along those lines. It's not that comfortable.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Thanks,

That seems to have solved the losing of the data. However, I am now struggling with displaying the results in a grid. Currently, this is not a hot item for this routine. But, this will be important in programs to come. I tried settign the grid record source as Alias and using alias.fieldname as the record source. I either get an error or a blank grid depending upon if I manually set the alias outside of the program. A bit confused. But, I am reading other posts of yours on other related questions. I am sure I will get this.

Thank you very much.
 
Hi Puebles,

Check for foxpro safeselect in Google or elsewhere to find samples how to refresh your grid’s contents.

Regards,

Gerrit
 
The grid. recordsource only has to be the alias, not alias.field, that's ideally set in the columns (and not in the controls inside the columns).

Use the grid builder.

Or create an SCX (based on a native form base class or a vcx form class), add the remote view into the data environment, drag from there onto the form canvas.

Bye, Olaf.



Olaf Doschke Software Engineering
 
Olaf, yes that is what I meant. My bad. Gerrit, thanks for the heads up. I do get the records imported tot able to display in a grid. However, they are all blank records.

baby steps it seams. I feel like a real newb.
 
> if I manually set the alias outside of the program.

Not sure what you mean with "outside the program".

If you use PRGs, stop doing so, form code goes into the form. the major part of a PRG is main.prg with a READ EVENTS and DO FORM mainform, and some SET statements, perhaps.
This is now Visual Foxpro, event-driven, not PRGs, no @SAY, @GET, no READ statements. The code is in the forms and controls and their events.

A form (typically) has its own datasession, not only its own data environment but also a private session, so you don't open data in a PRG and then start a form displaying that, data access is part of the form, the form starts its datasession and reads its data, self-contained (OOP encapsulation).

Want to parameterize views? Then set them to be used with NoDataOnLoad, set the parameters you may get via form.init parameters and then REQUERY() the view cursors to fetch data parameterized.

REQUERY() also means you don't get grid reconstruction problems, you don't set Recordsource after fetching data, you set it at design time, you keep it at what it is and you REQUERY views, that is "safe select" without needing to ZAP and insert into the grid cursor. Grids and Views always were simple to work with in that aspect.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Form Init
USE FoxLocalRequests.dbf ALIAS FoxLocalRequests exclusive
=cursorsetprop("buffering",5,"FoxLocalRequests")
SET MULTILOCKS ON

This might not be relevant, but be aware that you must issue SET MULTILOCKS ON before you establish buffering. That won't explain the behaviour you are seeing, but it is something to keep in mind.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Thanks everyone. I am up and running. I realized the problem last night as I was walking out the door. In my many attempts to get this to work I moved the table out of the database and used it as a free table. I later moved it back into the database. The field names truncated and it totally slipped my mind. Hate to admit it.

Thanks to everyone on this thread I am cruising now.

Is there a way to mark this topic complete? answered?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top