filepro wish list

[Robert Haussmann]

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

[...]

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

Interesting scenerio, but in all fairness, *should* this work?
I suspect that it "works" in filePro proper, but what you're
setting out to do is update an undefined record.  mySQL,
MS SQL, etc. are not record-based.  fp_id acts as a type of
bridge between the two systems.  

Given that this is somewhat of a special case, I'd suggest
handling it with a "delete" subroutine that uses low-level ODBC
to update that particular record (via fp_id), and enumerates
the fields, storing NULL in each one.

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

That's exactly how you have to treat them (great explanation).
That's also why, for our purposes at least, the low-level
ODBC routines make much more sense (when dealing with databases
that are going to be updated by external sources).

Bob