filePro to SQL

[Ryan Powers]

> Track field names as used, then add index numbers to the end?
> 
> some_field
> some_field2
> some_field3
> [etc.]

Exactly.

> In your defense, I think maintaining the edits is a complete waste of
> time.
> I see edits as an application-level function, not a storage-level
> function.

The issue really is that filePro edits are dual purpose. If they were
strictly field types it wouldn't be much of a problem, but as you say, they
are also used at the application level which muddles things quite a bit and
(I could be wrong here) is the primary reason that they are lenient as field
types.

Tyler asked something similar. I'll go into a little more detail in that
e-mail. 



> If the data remains sacrosanct during transfer, that's all that should
> matter.  Since the MySQL-based application will almost certainly be
> done in
> something other than filePro, it's best to leave bounds checking beyond
> field length and raw data type (int, char, varchar, et al) to the
> actual
> application code.  Edits are definitely something I consider app-
> centric.
> 
> I shouldn't think it's worth the R&D to even be bothered with them for
> a
> project like this, given the above.

Thanks for the encouragement. I wasn't 100% sure that it was the right move,
but now I am. Of course it isn't going to be appropriate for everyone, but
it does the job as far as I'm concerned.


---
Ryan Powers
Bulldog Software, Inc.
http://www.bulldogsoftware.com