Filepro-list Digest, Vol 63, Issue 23

[Fairlight]

Simon--er, no...it was Ryan Powers--said:
> filePro allows you to use multiple words for field names which isn't
> permitted in MySQL, so the only way I see around this is to alter them.

Underscore to the rescue!

> The second problem is that filePro allows duplicate field names.

Track field names as used, then add index numbers to the end?

some_field
some_field2
some_field3
[etc.]

> It isn't a straightforward transfer because that would be
> impossible. There are several field changes but the data remains intact,
> albeit the edits will not be. I considered retaining the edits but I've
> been down that road before and it really isn't worth the trouble. IMO it
> is best to do a text transfer and then clean and convert the field types
> in MySQL once you have them in the tables.

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.
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.

mark->