From: "Jason Wharton" <supportlist@...>

> Be sure not to miss his database reverse engineering sample that looks
> through the DFM to try and analyze a database from that, admittedly
> imperfect, point of view. It appears to provide a framework for exactly
> what we need.
>
> This could also provide a framework for helping people deal with a number

of

> issues in their usage of IBO. I'm excited to see what will come of your
> efforts.

In cases such as my own, database properties are set at run time after
reading settings from a data file so it would be hard (read impossible) to
get any information from the DFM. :)

On a brighter note, I am starting on what it will take to move a large
project from IBX components to IBO components. My large project may not be
so large to some of you, but it is to me since I'm the only programmer. :)
There are over 100 forms and units, around 50 datamodules and lots of custom
stuff packed into a little over 140,000 lines of code. I am strictly working
on adjusting all TIBxxx (IBX) components to TIB_ (IBO) components. This will
involve all database and query components as well as all input/display
components. All procedures and function calls will need to be adjusted for
the new types as well as the code within them.

I already have a project mover program built cause I got tired of doing it
manually. It takes any existing project I have and copies or moves it to a
new directory. It changes all the directory names inside the project files
to reflect the new directory. It even changes them in DFM files so I already
have that part done. Now it's just a matter of passing each file to another
routine that will do the modifications before saving it again.

Something that would really help me out would be a separate FB 2 compliant
SQL parser for pointing out potential problems in existing SQL as it's
transferred.

Oh well, back to work now... :)

Woody (TMW)