File handling/database management

Its not completely clear from your post whether you want to go the relational database route or the simple flat file route. That's basically the first question you must decide. The techniques involved vary considerable depending on which way you go.

flat ascii files will be fine, I don't think the conversion process is worth the trouble with the price of storage these days.

Both text (ascii or unicode) and binary data can be easily stored in either flat files you open, close & manage yourself, or in regular databases which would involve dealing with its Api, so the question doesn't really have anything to do with size. What does your data look like specifically, e.g., is it names and addresses, what?

Your basic warehouse business model
i need a parts database
a customer database
and an invoice database.
and need to use the information to be able to interface with a customer, take the order, adjust inventory, print an invoice, figure out profit, send billing statement, etc.
about 1,500 parts and about 300 customers.

Hey Taphofyle!

You're into database programming with that. Unless you are a coding guru, I'd recommend not writing your own file structures, i.e., file access/retrieval, for something like that. If you haven't studied database programming yet, I'd recommend you do so. In C++ your choices are connecting with databases through higher level OOP front ends such as ADO (ActiveX Data Objects), or the lower level ODBC (Open DataBase Connectivity) route. I personally do all my database work through low level ODBC. I have some examples posted here...

http://www.jose.it-berater.org/smfforum/index.php?board=378.0

That seems like what I needed to know. Thanks for all of your input.

Here is another ODBC example that uses MS-Access and the Northwind example database. It does not cover everything that can be done with ODBC, just the basics of how to connect, run a query and get the results.

MS Access was my first experience with relational databases about 15 years ago. It always amazes me to see so many people knock it for one reason or another (its not free like MySql, its not as robust as Sql Server, on and on). I've had nothing but good experiences with it, and it serves as an excellent tool to get started learning about databases, structured query language, relationships in data, etc.

So the thing to do would be to get your tables and relationships set up, and once that's done then look into a user interface front end to the database. Heck, the various GUI tools in Access itself might be enough. However, if not, front ends can be coded in any number of languages. C++ probably isn't the best choice, but its certainly doable. Historically I believe, most folks used Visual Basic for database front ends. Its simply easier.

MS-Access is a great database for small projects. Its ok for 1-3 simultaneous connections. Anything more and Access can generate file corruptions.

MS-Access is a great database for small projects. Its ok for 1-3 simultaneous connections. Anything more and Access can generate file corruptions.

Yea, that's the thing. I created our (my organization, i.e., where I work) main database about 5 years ago and it contains pretty many tables and lots of relationships. There are about 5 or 6 main users through my various front end programs; however, chances are small more than 2 or 3 would ever be performing transactions on it simultaneously. About two years ago another coder here added access to it through Asp.net for a particular type of database transaction that happens fairly infrequently - perhaps a couple per week. I consider this living dangerously; however, so far no problems.

I've mentioned many times that I thought we would be better served by mocving to Sql Server (we have several), but the way everybody looks at it is that if it ain't broke - don't fix it! Before I setup the Access database we had a miserable system we'd paid millions for which didn't hardly work and nobody understood. With Access everybody likes it and doesn't want to change. So we keep things pretty well backed up and hope for the best.

I guess I should add that i need to find a job using whatever skills I learn from this and therefore I don't need the "best" database, instead I need the most commonly used one, or at least one that is in my local newspapers want adds. Does that change the parameters?

Not really. The most useful and commonly used databases are known as 'relational databases' and the good thing about them is that they mostly follow the rules set down many years ago by all the big players in databases and those rules are ODBC. So, if you learn how to write a program that conncts to any particular one of these databases, then, chances are good that your program can switch to using another database with little or no modifications. For example, in my programming with Microsoft Access which I mentioned above, when I tested it with SQL Server, there were fairly minimal changes needing to be done to work wuth the latter. So what you need to do is get yourself some database to work with, learn a little SQL ( Structured Query Language ) , then see how you want to connect through C++ code if that's the way you want to go.