Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Am I misusing TableUpdate()?
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
00261437
Message ID:
00261575
Vues:
26
Jim,

Thank you for the thought. My toolbar buttons all return a message to THISFORM.Whatever()... Anything that will move the pointer or add/delete/save/undo goes through a DataChanged() and a WriteBuffer() to try to get around that Valid() issue. Most of the methods still depend on being able to figure out which is parent and which is child.

If I have a third table column in the grid for reference information, say a product description that is neither parent or child, ReadOnly, does that table become selected passing through? In any case, I wonder why the field default does not fill in regardless. I select the table before the append blank.

The key generation stays in sequence, it just fails to write one of them. Also, it never happens to the parent, and only to second or subsequent children. Of course the parent is always created first, and a new parent always has one new child. The same routines create both, and that seems to work OK.

I do a SELECT Parent
GO Recno()
to reassert pointers, and DO WHILE through all of the children to accumulate totals, or whatever, as I have always done. I have row buffering on the parent and table buffering on the child.

Am I forcing VFP to TableUpdate() something that then foils my TableUpdate()?

I am misusing something for sure! Well, I don't want to misuse you by moaning about it. Thanks again for your suggestion. On my Next() trip through the classes and the code I will pay particular attention to that point.

Al A.

>Please pardon my jumping in, but you mention a ToolBar.
>
>I case you are unaware, clicking a toolbar item in mid-edit *bypasses* (at least temporarily) the VALID of the field being entered when the mouse click happens. Possibly this is being done on a field that is 'key' to your key-generating routine???
>
>In any case, if theis sounds applicable, the sample has code that can be used to overcome this deficiency.
>
>Good luck,
>
>Jim N
>
>>>>I have a remote view of a VFP DBC table. I inserted several records from arrays, etc. into the view. Now I issue tableupdate() at the click of a form button and nothing happens - no records are written to the table.
>>>>
>>>>Am I misusing the function because I didn't read from the table into the view first? What's the best way for getting the view info into the table?
>>>
>>>NO, you don't need to REQUERY the view before updating from it. Your problem lies elsewhere. In addition to Jim's advice, check to make sure that the view is set to updatable, a key field is specified, and the proper fields are marked as updatable.
>>
>>Eric, Jim and Steve,
>>
>>I find myself asking this thread question more frequently. Is there a connection between this, the thread "Theory of lost data" from around 08-16 to 08-20, and the behavior discussed in the FoxTalk article by Maskens and Kramek "Where do you want to GOTO"
>>
>>I have several applications that all use local tables and parent/child form header/grid style, and allow data entry on grids, and do not use views. Depending on the position and the the current control, I interpret toolbar clicks as adding a parent or adding a child on whether the call came from the grid or not, hotkeys and rightmouse menus as well.
>>
>>Defaults for the primary key fields and foreign key fields come from the stored procedures when the record is added. Most of the time this all works, but sometimes I get a record saved that has a blank primary key field. Sooner or later it would happen again, and then I have a PK violation, etc.
>>
>>Since I could not figure out what was causing it, and the input from the users about what they were doing when it happened was sporadic, I mostly responded by throwing TableUpdate() and Refresh() code at it, but only made matters worse.
>>
>>Using debug output and wait windows and so on I can see the new key being generated correctly and the RI code running. Should I issue a TableUpdate() immediately, upon adding a new record, or do I have to check that the stored procedure defaults in the field definitions do the right thing after the TableUpdate()? I will do as you and Jim suggest and make sure I have all the parameters in effect. Isn't it possible to do it with child grids directly?
>>
>>Thanks for your thoughts
>>
>>Al
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform