|Subject:||Re: Re:tc.add stops working
|Date:||Wed, 27 Dec 2017 09:56:51 +1000
|From:||"Phil Hassid" <philhassid@ozemailDOTcomDOTau>
Thank you for your response. There is no primary key on either table, and
there never has been. (Both of these tables are created purely for the
purposes of this program, hence also the large number of fields. There are
over 400 regular tables in the database itself, mostly with 10-30 fields,
and all with keys and numerous secondary indexes).
Any other suggestions would be greatly appreciated.
"thies" <email@example.com> wrote in message
> Hi Phil,
> first guess is the primary key
> Add uses as far as I remember True and False as parameter for add
> and update as default parameters.
> So check the primary key of the destination table.
> "Phil Hassid" <philhassid@ozemailDOTcomDOTau> Wrote in message:
>> Hi All,
>> Haven't been here for many years.
>> I use P8. Program containing about 750 lines of code that has worked
>> flawlessly for many years (including last 8 or so on same XP Pro
>> contains a table add
>> Both tables are first opened with an error trap (and no error ever has
>> flagged), tc1 is emptied, then after the add both are closed and used
>> in the program. This (update) segment of the code is only triggered
>> occasionally, where as the rest of the program is used many times a day,
>> this occasional use of this update segment is essential to lead to valid
>> results from subsequent uses of the rest of the program.
>> About a year ago this tc.add suddenly stopped working. Because it was
>> used occasionally I discovered the telling fact that immediately after
>> running the program (with the tc.add failing) the tc2 table was exactly
>> it should be and the tc1 table was still empty but in the correct
>> (whereas it should be the same as the tc2 table both in structure and
>> contents) and if I simply did a manual add of the tc2 table to the tc1
>> I could then run the rest of the program and get correct outputs, so I
>> used that as a workaround.
>> There have been no program changes, no OS/System changes, no table
>> changes, nothing. The sizes of the tables are small by your standards
>> (<15,000 records, although 236 fields) and have increased in size only
>> incrementally over the years. Both tables have DB, TV and FAM files only.
>> The TV file of the tc1 table did alter about a year ago but I am 90% sure
>> that that was after first discovering the problem, then going into table
>> restructure to look around, then on exiting table structure accidentally
>> accepting rather than rejecting the changed table view, so seriously
>> that this is related.
>> Can anyone think of some generic reason this might happen? TIA
> ----Android NewsGroup Reader----