Dear Support,

when reorganizing table tdsls041 table we get following attached error.
"Error during reconfigure tables,check your logfiles"

Awaiting for your reply guys

Regards,
Hardei

Hi,

There was no attachment in your post. Is there an error number?

- George

delete garbages from table ttadv500 to 505 in company 000 and try to reconfigure it again...

regards
yashwant

delete garbages from table ttadv500 to 505 in company 000 and try to reconfigure it again...

regards
yashwant

Do NOT do that..

Post the error from the logs, or talk to support or you can lose data.

Dave

hi,

But Mr Dave, Why ? I have solved problems related to reconfigure by doing this only...

yashwant

Yashwant,

I agree with Dave. Try to analyze the issue instead of jumping to fix something without proper investigation of the cause and/or symptoms. If you remove any tools information and something is messed up on your system then it is your mistake and your Baan Support can be declared void. They can be nice and still help you out. You should not be tweaking tools table information unless you really know the Tools Internals.

Here is a Tools patch release information, why that information should not be removed-

SolutionID 221439
CreatedBy Thuijls,Hans
CreatedOn 2007-06-14
ModifiedBy Wal,Geert van der
ModifiedOn 2008-01-15
VerifiedBy
VerifiedOn

StatusDescription
Published TypeDescription
QR: Error Standard Software

Solution Description
English A restart should only reconfigure tables which are not successful reconfigured
TOOLS VERSION(S):
7.6_a2, 7.6_a3

SITUATION IDENTIFIED IN:
"Convert to Runtime Data Dictionary" (ttadv5215m000)

SITUATION DESCRIPTION:
In session "Convert to Runtime Data Dictionary" (ttadv5215m000), when a reconfiguration is restarted after the session has stopped because of errors, undesired messages appear in the logfile/event viewer.

This is because succesfully reconfigured tables are reconfigured again.

SOLUTION DESCRIPTION:
The tables that have been reconfigured succesfully are skipped when reconfiguration is restarted. The error messages will not occur anymore.

hi,

But Mr Dave, Why ? I have solved problems related to reconfigure by doing this only...

yashwant

To add to what NP posted -

You don't actually solve any problems if you remove the data from the tools tables.

Here's an example of where deleting the tools data fails catastrophically:
During a reconfig you run out of space in your tablespace, So bdbreconfig fails on import of the R file.
The R file has all of your data in it and is 10GB. you've managed to import 10Megs worth of data before erroring.

You seeing an error, delete the tools data.

You restart your reconfig.

__Best case__
Baan doesn't have any reconfig info so it doesn't really do anything. You don't get a new DD in place. (so your reconfig was pointless) and you have a table with 10Megs of data going into production on monday.
You realize by the 606 (maybe 512 if you're lucky and have more than 1 company) errors fairly quickly in the day that you screwed up and call baan support who tells you
A) bring the system down ASAP to stop people from adding new data to that table.
B) how to recover the other 9.90GB from your R file.


__Worst case__
You start a reconfig so Baan tries to reconfigure that table again
destroying your Backup R file with the new, smaller one. It begins the import and Vollia it worked this time. you let people in the system on monday and if you're lucky you get 606s again.. or, more likely people work for a few hours and adding new data to your other tables, your DB is now out of sync. You - start looking for a new job and tell the system admin and DBAs to pull out Friday's tape backup and you're down all day.


So, to sum up. "error during bdbreconfig" is about the worst thing that can happen to an admin if he doesn't know the system like the back of his hand - call baan support. I wouldn't even bother with us on baanboard for that one because normally those errors show up in production and you just don't have the kind of time to sift through / wait for whatever answers we might have for you.

Dave

Hi,

I faced the same problem.

The Infor Support asked me to delete that tables (ttadv501 to 505).

Now the problem still there.

I dont know whether they are giving me the right solution or not.

I dont know who should I seek for help anymore if the principal cannot give me the right answer. ADOI.....

There are times when deleting the data from those tables is 100% correct.

You just need to know which those times are, which *hopefully* your baan support reps know.

Dave

Hi Dave et.al.,
you wrote "you let people in the system on monday " - does that mean you would not reconfigure during regular business hours with users on the system?
Also I have a related question: when running a reconfigure tables do you select 'Create rows before index'? Do you select 'Runtime Directories'?
DBA's have told me both yes and no?

Howdy,

A friend of mine told me that someone had posted to this thread.

FYI I stopped doing Baan like 6 years ago so i may not be the expert any more =).

But no you shouldn't do a reconfig when people are on the system. It will lock tables and cause all sorts of problems for them.

In most cases Create Rows Before Index is faster. I would usually run it with that on.

Runtime Directories dumps the runtime data to disk, so usually you want to run that as well.

Agree with the general sentiment that you should understand what happened and why before you take action. I'd suggest taking backups before any clearing of the ttadv tables as well as backup any "R." files of in-process bdbreconfig before taking any action.

Regarding reconfig when people are on the system, I would generally agree it is safest, best practice, ideal for people to not be on the system, but some of this depends on what ERP version and database you are on and what type of change is being done.

For example ERP-LN during reconfig to add an index could issue ORACLE statement to add an index which technically could be done with users on the system. If it is a type of change the reconfig is going to do a table dump to R. file, drop table, create table with new schema, load table from R. file you definitely do NOT want people trying to use the table.