Paradox Community

Items in pnews.paradox-development

Subject:Re: tc.add stops working
Date:Wed, 27 Dec 2017 13:42:14 +1000
From:"Phil Hassid" <philhassid@ozemailDOTcomDOTau>
Newsgroups:pnews.paradox-development
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
> 




Copyright © 2004 thedbcommunity.com