Hi Everyone,

I've been geting a lot of 305 errors lately. This happens for normal tables and also for 000 (tools) tables.

Already put ISO_BIN locale for all the users and the respective file in the $BSE\NLSINF directory.
Also created this new locale in the respective locale sessions as a lot of Baan support solutios refer.

Still I sometimes get those errors.

Can someone give me a suggestion?
(for company 000 and the others)

P.S.:
Details of this environment:
BIVc4; SQL Server 2000; Windows 2000.

6.1c.06.05

What errors do you get prior to the 305? Is it possible that your database parameters are a bit too tight? No data/index problems lately? Does reorganisation solve the issue? Are characters with high ASCII value (+127 bits) involved?

Hi,

Thanks for your prompt answer.
Answering your questions:

-No errors appear before error 305
-Tried to reorganize one of the tables where this occurs (tdrpl100) and did not have success (Used session ttaad4225m000 and not bdbpre/post).
-No data/Index problems lately.
-I think there are post 127 characters involved...

-In terms of database parameters, as this is MSQL, what parameters are you refering to?
(We migrated recently from MSQL7 to MSQL2000)

Thanks a lot.
Fred

PS: checked again the ISO_BIN file and it has (sort) in the first line and (end) in the last. Is the last line OK?

One database parameter I can see in msql2000 is

Collation Name: Latin1_general_bin

This parameter is not visible in msql7.



Thanks
Fred

FYI I supply bellow the db_resource file

dbsinit:01
lock_retry:0
bdb_max_session_schedule:50
msql_65_schema:1

Thanks
Fred

try removing the statement from db_resource file.

msql_65_schema:1

How did you upgrade from SQL7 to SQL2000? My guess is you bdbpre from SQL7, upgrade database then bdbpost to SQL2000.

Also I expect the line added

use_shm_info:0

Hi Benito,

Thanks for your answer.

The upgrade was not done as you say.
We used the upgrade manual:
"U7648A US - SQL Server 2000 upgrade Guide fo BaanIV and BaanERP"

Basically we just insert the MSQL CD and it upgrades the MSQL 7.0 database to MSQL2000.

The value you refer:

msql_65_schema:1

came from a previous upgrade (from MSQL 6.5 to MSQL7) some years ago. Should I remove it?

Will add the parameter
use_shm_info:0

yes, remove it and test the tables in question.

Hi,

Tested removing the parameter and did not work...

Also dumped data/dropped/created/imported data on one of the tables and the problem is still occurring.

It must be something else this time, but what?


Thanks
Fred

Does the SQL stored procedure get dropped
when you drop the table? If not, try removing the procedure in Enterprise Manager.

Dave

Just curious. did you run the stored procedure sp_updatestats on your database?
Have you run checkdb? Can you query your tables using Query Analyzer? Can you update your table row using Query Analyzer. Run these checks on you database first.

Error 305 means a wrong record was returned. I also hoped you run those optional tests Baan recommends after upgrading to SQL2000. I'm not sure about the porting set issue. I have older porting set than you so I assume yours should be fine. Run the Check Table session in Baan to see all the tables that have this error. I would recommend working on one table - preferably a small one. Drop the table. recreate. add one record. try querying. good luck.

we recently upgraded to SQL 2000 from SQL 7, and also had error 305 show up.
When we called Baan Support, they told us that there is a bug in the current porting set which does not work with the parameter "MSQL_ARRAY_FETCH" that the documentation recommends putting into $BSE/lib/tabledef6.1.
Porting set 6.1c.06.07 will have the fix, but not yet available I believe.
We removed "MSQL_ARRAY_FETCH=1" from tabledef6.1 file, and it fixed the problem.

correction...
I just checked Baan support site, and porting set 6.1c.06.07 is now available. It should contain the fix for error 305 and MSQL_ARRAY_FETCH parameter.

Hi all,

Thanks for your help, everyone.
Will try your suggestions next week.

Will posts the results here.


Fred

Hi Everyone,

As BBailey suggested, removed the parameter form tabledef6.1 and it seems the problem is solved.

Thanks a bunch
Fred

Hi Again,

Just to wrap up this thread, I decided to post here the last events:

After removing the parameter

msql_65_schema:1

from db_resource, I started getting error 512 on the following tables (for all companies):

tcedi750
tuddc100
tuddc110
tuddc901
tuxch001
tuxch901
ttaad502

and (more problematic) in company 000:

ttaad321
ttaad322
ttaad410
ttaad502
ttadv304 (big trouble)
ttadv335 (big trouble)
ttadv364 (big trouble)
tttss010


Of course it seems simple right now but was a difficult to discover the cause of such nasty 512 errors.
(The strangest thing is that the table format is exactly the same. If you remove the parameter, you'll get 512 errors, if you put it again the errors disappear).

So, the conclusion is:
If you have the "msql_65_schema:1" parameter in db_resource from a previous update MSQL65 to MSQL7 do not remove it....

Will create a new thread to discuss this parameter problem problem

Fred

you can remove it, but you need to bdbpre the tables with error first. that means you have the text files out of the table. then remove that statement msql_65_schema and create tables from sequential dump. you should have no errors after that.

the msql_65_schema uses the old sql 6.5 schema as the name implies. the way i understand it, it breaks down longer fields into several segments. sql 2000 can handle longer fields thats why it doesnt need the statement but you need to re-import the rows before it recognizes the longer fields.

for some reason i did not put the statement msql_array_fetch on my installation, thats why i did not get the same problem as you had. i guess i was wary about putting something i dont fully understand. baan should have tested these parameters with older porting sets before putting it into print.

Hi Benito,

Thanks for the update.
Will try the bdbpre/bdbpost later on the test system, when I set it up.

For now I'm going to let things stabilize a little.


Fred

Due to this error (305) A wrong record was returned. Probably index for those tables may be corrupt.Please repair index for those tables which are showing same error. You can repair it at database level or application level.

Best Regards
Sanjay Kathuria

too late Sanjay, check the full posts on the thread :)