filepro wish list

[Walter Vaughan]

Robert Haussmann wrote:
> As far as "automatically start working with the databases" goes,
> I wouldn't go quite that far.  Depending on your specific need
> (high level vs. low level connectivity), however, the setup can
> be pretty straightforward.

...The following only applies to high_level ODBC...

Remember I am the *Biggest* fpODBC fan in the world. What does not work 
(or if does please someone show me my error), is that filePro cannot 
deal with deleting records stored in an ODBC database and then store 
data in that deleted record. At least in MySQL.

So if all you want to do is add records, and build reports, it'll work 
like peaches and cream. Try to update a record that has just been 
deleted and you're up in smoke.

In My Opinion, there needs to be written an export tool that would build 
in the DBMS's a stored proceedure that would set a deleted record flag 
and null out the data, but still allow linkage to a record number. Thus 
the record will appear  blank, but will exist as a "record" in the DBMS.

I Am Not An ODBC Expert, but if an OBDC Data Source recieved a "filepro 
type" delete, and would just "work" like filePro and kick of a stored 
procedure to accomplish the goal, then we'd have something.

[.. steps to reproduce problem..]
Creat a table in MySQL with two fields
Name		Type	Length
-----		------	-------
RN		int	8	Primary Key
Data		varchar	10

Connect using MySQL ODBC driver version 3.51

Create a filePro ODBC file based upon the above table

Add three records with text. filePro properly handles and creates record 
numbers as needed.

Delete record number two.

Try and update record number two.
Here's where it gets fun, and so far I have not seen a way to deal with 
configuring around that.

Secondly, filePro only uses it's indexes. If the data is modifed by the 
external means, you will have to run dxmaint before using an index. In 
essence, you have to treat all indexes as demand indexes that are only 
as good at the time you create them.