Good morning folks...I have a pseudo concept question. I have a trio of unix text files that I need to load into an Access database, and then do a comparison for matches (knowing one field will never match).

My original idea was to create a VB application to parse the delimited text (open file, place data into specific fields within a table for each file) and then automatically run a comparison query between the separate tables reporting a count of the matching fields

In order to do this I was thinking a four button app, one button for parsing each file into a table, then one button to run the comparison query (perhaps a fifth for creating the database)

Thoughts? Constructive criticisms? Would this better be done in one of the C family languages?

Recommended Answers

All 3 Replies

Is this going to be an ongoing periodic task, or a one-time load? It would make a difference in design.

If it's one-time (and assuming you have MS-Access on a Windows client), you could do the table loads using the MS-Access Import wizard (once for each table, assuming they have different formats), then write a single query to join all the interesting table data for side-by-side compare. It would save a bunch of coding.

If it's ongoing and periodic, and you're always going to have the same input files, just make it a one-button form. Click once to load the files and perform the compare. If no database exists, prompt the user to create. If the database does exist, use it.

As far as coding language, you could use either of those languages. Personally I wouldn't use C or C++ because I'm more familiar with VB, but there's no technical reason not to. As long as you are comfortable getting to MS-Access via those languages (either through ODBC or OLEDB APIs).

Another extra value-add would be formatting and displaying the output of the report.

Also, assuming you have MS-Access, you could just write the app all in Access VBA. then you could use the Access object model in your code to invoke the import wizard features, again with a one-button form. You wouldn't have to worry about creating a new database, just clearing out old data before you re-load.

Good luck! Be sure to post a description of what you actually wind up doing to share with us.

Thanks for the input BitBit. The use would be ongoing. I am a C++ coder venturing into the VB/VBA world so either works for me. I had not thought of a direct import, but I'll try that to see how it works before I venture into the code. The reason I was thinking full VB application rather than writing a VBA Access mod is that I would not be the only one using it. There are some less tech savvy folks in the office that I would rather not have to teach how to import mods (trying to make comparison analysis easy for them). If you have any additions/modifications to your original post, I'd be glad to hear them, and again...thank you for the ideas. I will replay to the post with the plan and mark it solved when I decide how to go.

I would recommend VB over C for working with Access database files. Writing code for C is more complex for working with Access Databases. Of course, a typical C programmer likes things more complex, anyway.

But Visual Basic 5, 6 was basically built to run Access databases and is fairly easy to implement. You may have finer control in a C program, but I'll doubt you'll need it or want the headaches of having to figure it out in C.

I've been programming for years. But for Rapid Application Development, I would say you just can't beat VB.

Argh. The C programmers are going to tell me to stay on the VB forum again.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.