help with GL10.1

Does it eventually timeout in LID? It should give you a lacobrts error so you can see what the problem is....also look at ladb.log and see if you have any errors...

I checked the SQL server and it showing suspended process with the following scripts.

(@P1 smallint,@P2 char(12),@P3 smallint)select JSQ.COMPANY, JSQ.JRNL_BOOK_NBR, JSQ.FISCAL_YEAR, JSQ.SEQ_TRNS_NBR, JSQ.JBK_LAST_SEQ from JBKSEQNBR JSQ with (index(JSQSET1)) where JSQ.COMPANY=@P1 and JSQ.JRNL_BOOK_NBR=@P2 and JSQ.FISCAL_YEAR=@P3 order by JSQ.COMPANY, JSQ.JRNL_BOOK_NBR, JSQ.FISCAL_YEAR

That looks kinda weird...do you use Journal books?

No, we don't use the journal book, so I have no idea why it's hanging with that script. I just double checked the JBKSEQNBR table and we have absolute no entry in the table also. I can get in GL10 fine and make inquires. But I can't change any data in my companies without an endless hourglass. Any suggestion would be appreciated. Thanks.

What apps version are you on?

8.0.3 MSP11

How big can GLMASTER table be? What's the limit of Lawson? I think my GLMASTER is so big from implementing the new chart of accounts because of state requirements...

My old GLMASTER is roughly 58,000 rows big...

My new GLMASTER is roughly 275 millions rows big...

Apparently GL10.1 timed out from that huge GLMASTER table. After I shrunk it down to 1 company (for testing), the GL10 works again.

So what's the limitation for Lawson for GLMASTER table?

Thanks.

So, do you get a timeout? You should eventually. There really isn't a limit on GLMASTER, nor there really should be since it theoretically can be as big as your organization requires.
Did you open a case with Lawson? If not, you should.

Yes, I have a LIS case going with Lawson for this problem. No solution so far.

I got curious and started to unload all the company and load them back in one by one and do timer on the runtime.

With around 100k rows in GLMASTER, processing time is instant in GL10.

With around 7 millions rows in GLMASTER, processing time is roughly 1-2 minutes in GL10.

I am adding another 50 millions rows in GLMASTER now, and if what I expect is true, the runtime is gonna be pathetic.

Is there anyway to bypass the excessive runtime just in case this turned out to be true?

I am still having problem with GL10. The followings are my findings so far:

GLMASTER rowcount/runtime

100krows/instant

8millionsrows/1-3minutes

62millionsrows/40-60minutes

114millionsrows/3hours-3hours30minutes

(I have 275millions rows total for GLMASTER)

=========================================

I have set up animator to see what GL10 is doing.

And it's sitting at FINDBLTDB processing the data. The SQL 2005 activity monitor shows the physical IO are constantly increasing, thus, it's not hanging.

Any advise?

Have you checked the GLMASTER GLMSET2 index?
- Run verifymsf2000 to see if it's missing
- Run bldmsf2000ddl -URI to rebuild it

I think I have found the the cause of problem.

With the same database backup image.

SQL 2000 - runs fine

SQL 2005 - really slow (eventually it runs through) with GL10, PR295 so far, all the other runs much faster with improved hardware.

Our conversion process use the typical backup/restore function. Rebuild index and update statistic etc.

On the lawson app server, we installed native client and management studio and configured alias to access the SQL 2005 server.

Under our LAWDIR/productline/MICROSOFT we made the changes to DBSERVER and DBNAMES according to lawson support document.

I have rebuilt the database index and updated statistic.

Somewhere is not ok it seems... what am i missing? 8.0.3.7.286 is the built of the environment which should support SQL 2005...

 

Is the database on a different server than the Lawson app server. If so, make sure the same version of the MDAC is loaded on both. Also, just a wild guess, but did you check the collation sequence on the database?

MDAC checked and collation is correct.

I did solve the problem by adding one line of code into GL10PD source file and recompile.

The animator shows it was looping in the 220-EDIT routine and it was going thru the entire GLMSET2 index, thus the excessive runtime. I added DB-COMPANY variable under the initialize section of the code and it was able to stop the looping and everything seems to work now.