We are an MS SQL shop and are planning on defragging our Lawson tables.
Does anyone know of any pitfalls in doing this?
Some of our users are reporting jobs taking longer to run and we think this may help that problem.

I can't respond specifically about MS SQL- 'cause I'm a Unix Geek, but I have a client who does it regularly with DB2 and the throughput gain is measurable. Again, I'm not an MS SQL guy, but if you have the opportunity to do the MS SQL version of "update statistics" it's a great idea as well.

Thanks schroncd, I'm not a SQL guy either but am trying to learn as I go.
Our SQL DBA says that he can do the defrag but wanted to get Lawson's recomendation, which, if it's like most things dealing with backup or DB maintenance they basically tell you it's up to you to deal with it as you see best.

My worry is that doing the defrag may actually frag something in Lawson.

Is it possible to

1) create a copy of the database
2) defrag that copy
3) Link Lawson to it
4) Test it till the cows come home and then do some testing with the cows
5) Switch back and see what you've learned

I might have over simplified it a bit but I would guess that shouldn't be too hard if you have the space :merc:.

I know enough about the way Lawson uses databases to tell you that you aren't gonna mess up a thing in Lawson by defragging your tablespaces, no matter which RDBMS you use. As far as Lawson is concerned it all stops at the proprietary database driver - the database itself is just a "black-hole" into which Lawson throws data and then sucks it back out. If you can make it perform better on the RDBMS side, have at it - Lawson will not care.. And your users will appreciate it!!

There's another thread in another section that I started where I'm trying to find out if there's any way to speed up Lawson running SQL Server at the back end. Please let us know what happens when you have successfully defragged your system -- if it speed things up, I will be very interested to hear about your success! :bow: