SQL DB conversion growth

I Feel your pain Darren. We went through that mess before getting to where we are now.
Fortunately, we got hooked up with some tech support people that had been around awhile and understood the problem.
We came to Vantage 8 in Beta ll while running a partially implemented Vantage 6. Before taking V8 live (8.00.809c) we must have done 30 to 40 upgrades, data conversions, a handful of clean installs and importing some data in other than approved Epicor methods. Somewhere along the line we picked up a table IMVALRULE that stayed with us up to 8.03.305h. Problem was this table did not do anything until .400. The data conversion was failing for us because it was trying to create this table for .400 but would fail since we already had one. Naturally the table structure was nothing like it needed to be.
Once we deleted the IMVALRULE table from 8.03.305h the conversion ran clean. The other thing they had us do was run a program 803401NullFixer.r that ran through .400 SQL tables reformatting columns that had null values. That was an eye opener. We knew that Vantage did not like null values and were always careful in our work to not create any. This program ran for hours and says it cleaned up thousands of records. From what I could tell we had never done any work where the nulls were found (mostly user definable fields - but not all) and have to believe they were the result of Vantage conversion programs over our V8 life. We are finding 8.03.405a to be far more stable than any previous version we've worked with and believe the null fixer program has much to do with that. I'd recommend it to anyone who has not run it. Now if we can just get the db back down to a decent size we should be in good shape.

David J. Murphy
Information Systems Manager
A&A Machine & Fabrication, LLC
Elevating the Art of precision machining
and fabrication from concept to completion
Voice (409) 938-4274
Fax (409) 938-3925
www.aagroup.com





[Non-text portions of this message have been removed]
Hi all,

Have a srange situation with no ready explanation.
We currently run 8.03.305h on SQL 2000 32bit.
Have created a test environment on a new server running 8.03.405a on
SQL 2005 64bit, same code page.
Each time ( 3 now, using different methods) I take my production .305h
data to the .405a environment, the database grows from ~5GB to ~25GB
during the 300-400 schema change. Appears that only the .mdf is
growing; the .ldf is only slightly larger due to the SQL 2000 to 2005
conversion.
I've opened a call at Epicor who has not confirmed nor denied seeing
this before. My SQL 2005 disk analysis says the space is full of data
and indexes. Everything seems to work fine in 8.03.405a. I expected
some growth due to more tables and indexes but nothing like this. Has
anyone else seen this? Any SQL whizzes want to make a guess? We are
planning on taking 8.03.405a live on 9/22 but I can't get comfortable
until I understand what is happening here.
Thanks for any thoughts you can offer.
We don't do use SQL here but in a previous life I was a SQL DBA. It sounds
like your conversion isn't running correctly cuz nothing I can think of
would explain that. The only thing I could think to do is strip off all
indexing and put it back on. You can find scripts out there that will go
through and script out all the indexing, delete them and then put them all
back. But I seriously don't think this will account for 20 gigs worth of
data.



I have made a very similar conversion from 305k to 405a however I did this
in progress. My DB only grew by a couple of megs at most. New tables and
columns can not account for 20 gigs worth of data.



You may have to get both MS and Epicor on the phone together and let them
fight it out cuz the first thing Epicor is going to say is that it is a
MSSQL problem.



~Charlie



_____

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
david2murphy
Sent: Wednesday, September 10, 2008 3:33 PM
To: vantage@yahoogroups.com
Subject: [Vantage] SQL DB conversion growth



Hi all,

Have a srange situation with no ready explanation.
We currently run 8.03.305h on SQL 2000 32bit.
Have created a test environment on a new server running 8.03.405a on
SQL 2005 64bit, same code page.
Each time ( 3 now, using different methods) I take my production .305h
data to the .405a environment, the database grows from ~5GB to ~25GB
during the 300-400 schema change. Appears that only the .mdf is
growing; the .ldf is only slightly larger due to the SQL 2000 to 2005
conversion.
I've opened a call at Epicor who has not confirmed nor denied seeing
this before. My SQL 2005 disk analysis says the space is full of data
and indexes. Everything seems to work fine in 8.03.405a. I expected
some growth due to more tables and indexes but nothing like this. Has
anyone else seen this? Any SQL whizzes want to make a guess? We are
planning on taking 8.03.405a live on 9/22 but I can't get comfortable
until I understand what is happening here.
Thanks for any thoughts you can offer.



No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.16/1651 - Release Date: 9/10/2008
6:00 AM




[Non-text portions of this message have been removed]
We upgraded from 305K to 404 using SQL 2005 and our db didn't grow more than
100Mb. I know it is a pain, but have you tried doing an intermediate
upgrade in your test environment to 404 first, then to 405? I would be
curious if your db grows moving to 404 also.



Daniel

_____

From: vantage@yahoogroups.com [mailto:vantage@yahoogroups.com] On Behalf Of
david2murphy
Sent: Wednesday, September 10, 2008 3:33 PM
To: vantage@yahoogroups.com
Subject: [Vantage] SQL DB conversion growth



Hi all,

Have a srange situation with no ready explanation.
We currently run 8.03.305h on SQL 2000 32bit.
Have created a test environment on a new server running 8.03.405a on
SQL 2005 64bit, same code page.
Each time ( 3 now, using different methods) I take my production .305h
data to the .405a environment, the database grows from ~5GB to ~25GB
during the 300-400 schema change. Appears that only the .mdf is
growing; the .ldf is only slightly larger due to the SQL 2000 to 2005
conversion.
I've opened a call at Epicor who has not confirmed nor denied seeing
this before. My SQL 2005 disk analysis says the space is full of data
and indexes. Everything seems to work fine in 8.03.405a. I expected
some growth due to more tables and indexes but nothing like this. Has
anyone else seen this? Any SQL whizzes want to make a guess? We are
planning on taking 8.03.405a live on 9/22 but I can't get comfortable
until I understand what is happening here.
Thanks for any thoughts you can offer.





[Non-text portions of this message have been removed]
Well I would think they have seen it before. I called about it months ago when I was wondering why their
automated conversion process failing and leaving the database virtually empty and unusable but the size
had grown from 6GB to 25GB.

I just ended up running the SQL conversion scripts manually and it seemed to work better.Â


Â


----- Original Message ----
From: david2murphy <djmurphy@...>
To: vantage@yahoogroups.com
Sent: Wednesday, September 10, 2008 3:32:33 PM
Subject: [Vantage] SQL DB conversion growth


Hi all,

Have a srange situation with no ready explanation.
We currently run 8.03.305h on SQL 2000 32bit.
Have created a test environment on a new server running 8.03.405a on
SQL 2005 64bit, same code page.
Each time ( 3 now, using different methods) I take my production .305h
data to the .405a environment, the database grows from ~5GB to ~25GB
during the 300-400 schema change. Appears that only the .mdf is
growing; the .ldf is only slightly larger due to the SQL 2000 to 2005
conversion.
I've opened a call at Epicor who has not confirmed nor denied seeing
this before. My SQL 2005 disk analysis says the space is full of data
and indexes. Everything seems to work fine in 8.03.405a. I expected
some growth due to more tables and indexes but nothing like this. Has
anyone else seen this? Any SQL whizzes want to make a guess? We are
planning on taking 8.03.405a live on 9/22 but I can't get comfortable
until I understand what is happening here.
Thanks for any thoughts you can offer.






[Non-text portions of this message have been removed]