>>>Of course I know VFP is still the hands down best database tool around. This won't be database programming, though. A couple things I'm pretty interested in: document imaging is the field I'll be starting in. The company also does some machine control programming. I always wanted to do that.
>>
>>Wow... document imaging and machine control programming. If those aren't database programming apps, I don't know what are.
>>
>>JMO, but it seems like the company you're working for may be short-sighted, not you...
>
>I need to clarify ... the company I'm going to didn't tell me "this isn't database programming," those are my words. So I guess I am the one who's short sighted! :)
>
>Since you made me reflect on it, I definitely see your point that document imaging has a database element within it, i.e. tracking where all the document images are. But the scanning bit isn't database work, IMO.
>
>But I don't understand how machine control programming is a database app, or even has a database element to it. It's sending bits out a parallel port to control the movement of a robot arm or something. What database?
>
>- Rich.

By coincidence, your two examples are surprisingly appropriate to show why you might want to use database technology.

As for the "scanning bit" in document imaging, that depends on what the document imaging system is trying to achieve. If all it's going to do is store bitmaps or JPEGs, no database is required. However, please don't take this personally, but that is quite literally a "dumb" approach to the problem. A more ambitious - and more valuable - approach is to try to create editable and indexable documents (e.g. Word) via OCR. Take a moment and think about what OCR tries to do. It takes a mishmash of bits/pixels and imposes structure on them, in order to discriminate characters. It then tries to assemble them into words and sentences. IMO, a database is useful anytime you're trying to derive order from chaos. Then, at a higher level, you need to check your scanned words/phrases against a spell and/or grammar checker. Well, I can't say for sure, but I'd be willing to bet that the folks at Caere, Xerox, etc. are using database technology in their OCR products for these reasons.

Machine control programming is the same sort of thing. If all you want to do is make a tool travel from X1, Y1, Z1 to X2, Y2, Z2 you don't need any real database power behind it. Again, however, a database component can "add value". Here are two examples:

1. Suppose your software is used to control a mill to drill a hole in a piece of metal. The simple approach would be to "go through the motions" and program the drill path. A more valuable method would be to monitor the time to drill the hole (if constant force is applied) or motor torque (if constant feed rate is applied) for each piece drilled. As time goes on and the drill dulls, time and/or motor torque will increase. Production managers and maintenance supervisors are very impressed by an application that can predict when a drill bit is going to break before it does so.

2. When programming a robotic arm, there are often "prescribed areas" through which the arm mustn't move in order to avoid hitting human operators, other machinery, floor, ceiling, etc. A simple database could make it much easier to update these parameters if the robot is moved, new equipment placed nearby, etc.

As a mechanical engineer by training, and a programmer by vocation, I have long been interested in interfacing computer systems with the "real world". Whenever I've done so for clients, they inevitably want to be able to monitor "how the app is doing". This means reports - which means structured data - which means a database.

But it's not limited just to "real-world" apps. Ultimately, human beings want to monitor all their applications. Hence, my tagline...

Now's the time to get off my soapbox, before the blizzard of eggs and vegetables gets TOO thick...