Subject: | Re: tc.add stops working
| Date: | Fri, 29 Dec 2017 21:39:15 +0100 (GMT+01:00)
| From: | thies <thies.grimm@t-online.de>
| Newsgroups: | pnews.paradox-development
|
Hi Phil,
did you change the structure of the table.?
Rename your locale table, use tc.instantisteview to recreate it
and then try again.
Tc.add fails if the field structure is different?
Thies
--
"Phil Hassid" <philhassid@ozemailDOTcomDOTau> Wrote in message:
> Hi Thies and Steven,
>
> Thank you for your suggestions. I will look into these and report back.
>
> (I do keep a copy of both of the tables permanently in the PRIV directory
> because the table format and structure never changes for these two tables.
> It is only the data that changes - incrementally. As I get new listings or
> prices change or other things change with listings, I have to run this
> update section which draws info from the 400+ db tables to form the updated
> wider tables used in the program).
>
> In the meanwhile I wondered if somehow one tiny segment of my hard drive
> might have been corrupted whereby just the update part of the program was on
> this segment (because the rest of the program works fine ... although the
> update part is not a called subroutine stored separately as a separate
> entity, but is part of the whole program, so not sure if this could even be
> possible)? If it were possible, how would I even test for that and how would
> I relocate it elsewhere?
>
> Phil
>
>
> "Steven Green" <greens@diamondsg.com> wrote in message
> news:5a4392fa$1@pnews.thedbcommunity.com...
>> 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
>>
>
>
>
>
----Android NewsGroup Reader----
http://usenet.sinaapp.com/
|