transfering contents of one driver to another

How can I do this. Is there a program I can use.

Alright some info. We are upgrading are computers in work. From a networked P3 and p2 system to a server with a Xeon, and two p4 2.8 systems all networked together. Contained on the P3 system is the inventory for the store, information that cannnot, I repeat cannot be lost. Trying to inventory over 3 million used and new sports equipment items is not an opinion. So how can I do this?

dicecca112 said:

How can I do this. Is there a program I can use.
Alright some info. We are upgrading are computers in work. From a networked P3 and p2 system to a server with a Xeon, and two p4 2.8 systems all networked together. Contained on the P3 system is the inventory for the store, information that cannnot, I repeat cannot be lost. Trying to inventory over 3 million used and new sports equipment items is not an opinion. So how can I do this?

Click to expand...

I'm a programer/consultant and most of my work revolves around an accounting application that my company sells and services.

No offense, but your question gives me goosebumps. I can't tell you how many times I've seen clients try to save a buck and end up screwing themselves out of even more time and money because they don't know what they are doing.

I really don't mean to sound offensive... but I don't know how to put it more gently. You're scaring me.

I'm guessing that your inventory stored in a database? That's how most data of that nature is stored... if so, what database are you using and which version? That would be the most relevant question you could ask.

If the contents you with to migrate between machines is stored in a database, there are a lot of different things you might find. For example, a client of ours who is a brewery (great beer too!) had their data in an OLD version of btrieve -- there were no ODBC drivers available for that version in order to easily retrieve their data. They opted to use man-hours and simply printed their data to text files and used excel to manipulate things so we could move it to a SQL Server.

I've moved/manipulated data from all kinds of sources. You see some crazy **** sometimes. It's funny sometimes when you run into things and the client realizes just how bad their data is.

Well, good luck to you. Make you you've got a good backup before you start!

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.

couldnt you just get another drive, attach it to the computer and copy over the data? Or you could use Norton Ghost to create an image of the drive you want copied and place it over the new drive

What about leaving the "old" system on the network, and doing a file transfer via the network (to the new PC's)? Then, remove the Old PC's from the network. Forgive me, but I'm a dummy Seems feasible to me...

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.

Click to expand...

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!

Here ya go... there are plenty of docs here that might be useful to you. http://www.pervasive.com/integration/support/Installation_Guide.asp

Tell your boss that it's no small feat and to give you time for a test migration. If your uptime is important, don't do it without testing your migration first.

Mitch you rock. Thanks for the links. Let's hope this goes smoothly.