Question for Tommorow's QnA with KB

[Walter Vaughan]

This came up last night in the fpRoom, and since no one has posted any 
pre-questions yet...

1) when building a report in dmoedef, if you have no content in the 
header line, the number of lines that is allowed in the data section is 
one less than the number of lines that are defined per page. If the 
header is totally blank, why count that against the number of available 
data lines?

This is from Me...

2) What would be the sin in having a wizard that would migrate a filePro 
database to a third party SQL data store in a format that would work 
cleanly with a database abstraction layer that is designed to work in an 
  almost native format, rather than forcing filePro to deal with 
arbitrary datasource layouts.
(is that confusing enough?)
- Build a database in filePro
- add logic edits tables
- test and debug
- Run a wizard that exports any existing data to a SQL server and tells 
filePro to look on that SQL server for data. Filepro stores all hidden 
system and real fields on remote/localhost SQL server.

Then if someone has a need access the data with php/olap/neural 
network/SAS/Peoplesoft/Oracle_Financials/perl/visual_basic they can.

Does anyone understand the question? Instead of trying to make OBDC work 
on Unix, build in connectors that allow for data to be stored in a 
manner that filePro expects, rather than tying to make filePro work with 
any random/arbitrary ODBC datasource.

The end result is that we get all the functionality of our RAD tools and 
  yet for those things we do not write (like perl/OLAP) we have cleanly 
exposed data available for usage.

Middle ground if it were, but on filePro's terms.

3) fpDeveloper's Journal issues 6-8?
--
Walter