dicecca112 said:
oh yeah we have a ton of backups, but it's a pain to restore the system. Believe me I've done it twice, and my boss paided for the OT. The database is being moved to the same exact version. We use a program that I believe is called Pervasive. I plan on calling our tech people before I start and see how they would do it. They have the ability to dial in to our systems via PCAnywhere, and do anything. Just wanted to reassure my boss that it is possible and try to alleviate his fears sum.
Oh and on a side note. Our database is so bad that we have equipment that is supposedly in inventory that we haven't had in the store physically for 5 years.
Ahhhhhh yes... Pervasive. Pervasive SQL, formerly known as btrieve, right? They changed the name of the database to Pervasive SQL 3-4 years ago.... I think it may have been to get away from the btreive stigma.
The accounting package I work with used to be written by a software company called Great Plains. Great Plains was later purchased by Microsoft. Great Plains had a few product lines and you could purchase their product that ran with either Microsoft's SQL Server, Ctree (I'd only recommend for a single user), or btrieve... later known as Pervasive SQL.
They went through many licensing models and eventually they would allow The licensing for the Microsoft SQL Server instead of btrieve, but the cost was about 20% more.... even though the initial cost was 20% more, my companies would try to make clients realize that the overall cost of ownership of the product on Microsoft SQL was LESS than that of btrieve.
Btrieve was just a mess. I haven't really worked with it in 3-4 years, but the last big project I had involved reading and writing records using their ODBC drivers. I found that a company called Merant had better drivers for Pervasive's product than Pervasive! The ODBC drivers Pervasive provided couldn't write to variable width columns, for example. Not to mention that Merant had a considerable speed increase.
I also remember another client we had... this was probably in 1999. They had their server lock up and they literally had to pull the plug on it... no kidding. Somehow something got caught in a loop and when I started digging around, I found one of the btrieve tables had over 14,000 primary key violations!!! If you work with databases, you'll say "You can't do that." Well... I've seen it. The damn thing would blow up because the table had become so corrupted. I was eventually able to dump the contents into access, clean up the data, and re-import it.
Okay okay... sorry, I know I went off on a tangent, but I do actually have a point. It's my opinion, after working for two companies with a LOT of clients in between then who ran both btrieve and SQL Server, that you would be MUCH better served on a different database platform. I've worked with Oracle, Microsoft SQL Server, MySQL, btrieve, Ctree, Btree, Foxpro, and all other kinds of data sources... I think my experiences with btreive were the worst. I just saw too many clients who had trouble with their btrieve installations.
If I recall, I belive all the data is stored in .btr files. If you use ODBC connections, you'll have DDF files too, so that clients making their connections will know which columns to expect, indexes, etc. If you have client machines using ODBC connections, you'll need to make sure that they are pointed to properly generated DDF files (otherwise they might end up talking to your old machine!).
If I were you, I'd just go to the pervasive site and crack open some manuals on installing/migrating your data. I haven't touched the thing in some years and even if I did... I know I couldn't tell you everything you need to know in a messageboard thread.
Typically what we do, when migrating a client, is we perform a TEST migration. You migrate the data to the new platform simply to ensure that everything is going to go smoothly. Yes, it's time consuming, but it's not nearly as painful as trying to move your **** and finding out that it doesn't work! Do your test migration, document your steps, make sure that it works, and after you've verified everything, do it for your production data!
Again, good luck!