Subject: | Re: tc.add stops working
| Date: | Wed, 27 Dec 2017 07:32:54 -0500
| From: | "Steven Green" <greens@diamondsg.com>
| Newsgroups: | pnews.paradox-development
|
check for keyviol, and other potential errors? that would be records, not
the whole table, but it's something to check for.. or a full/write lock on
the destination table from somebody else
--
Steven Green
Myrtle Beach, South Carolina, USA
http://www.OasisTradingPost.com
Collectibles and Memorabilia
Vintage Lego Sets and Parts
- and Paradox support, too
"thies" wrote in message news:5a438e59$1@pnews.thedbcommunity.com...
Hi Phil,
do you need the table just as a tc in memory? Read the data in a
tc in mem. Otherwise try a tc2.instantiateview and open the tc1
on this table.
Thies
--
"Phil Hassid" <philhassid@ozemailDOTcomDOTau> Wrote in message:
> Hi Thies,
>
> 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.
>
> Phil
>
>
> "thies" <thies.grimm@t-online.de> wrote in message
> news:5a422235@pnews.thedbcommunity.com...
>> 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.
>> Thies
>>
>>
>> --
>>
>>
>> "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
>>> computer)
>>> contains a table add
>>>
>>> tc2.add(tc1)
>>>
>>> Both tables are first opened with an error trap (and no error ever has
>>> been
>>> flagged), tc1 is emptied, then after the add both are closed and used
>>> later
>>> 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,
>>> but
>>> 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
>>> only
>>> used occasionally I discovered the telling fact that immediately after
>>> running the program (with the tc.add failing) the tc2 table was exactly
>>> as
>>> it should be and the tc1 table was still empty but in the correct
>>> structure
>>> (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
>>> table
>>> I could then run the rest of the program and get correct outputs, so I
>>> have
>>> used that as a workaround.
>>>
>>> There have been no program changes, no OS/System changes, no table
>>> structure
>>> 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
>>> doubt
>>> that this is related.
>>>
>>> Can anyone think of some generic reason this might happen? TIA
>>>
>>> Phil
>>>
>>>
>>>
>>>
>>
>>
>> ----Android NewsGroup Reader----
>> http://usenet.sinaapp.com/
>
>
>
>
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
|