fileProODBC (was Re: OT: Filemaker 8)

[Fairlight]

At Mon, Feb 06, 2006 at 10:19:05PM -0700 or thereabouts, 
suspect Tyler Style was observed uttering:
> 
> Yup.  We have been talking about clients and servers.  Totally agreed. 
> As I keep pointing out, filePro is primarily a database backend, a 
> server.  I don't think most people think of it as being a client 

Okey, stop right there.

"database backend" ne "server"

One does not necessarily imply the other.  I can count off memory at
-least- half a dozen database backends that had no networking at all.  Many
existed before networking became commonplace, and some continued past that
era.

> interfaces provided are generally used for is accessing fP data.  The 
> vast majority of database backends (ie, servers) have ODBC connectivity 
> for client applications to use to connect to them and manipulate data. 

Majority (now), yes.

> A developer would thus expect to have such available to him for 
> connecting to a filePro datasource, especially given that fP has been 
> around for yonks and yonks.  It doesn't, which surprises people, 
> especially when they hear that filePro has ODBC.  Because they think of 
> filePro as a database server.  Not a client.  And database servers are 
> generally accessible via ODBC.

Then they haven't read even the first paragraph of the product info on the
web site for filePro ODBC  (http://www.fptech.com/Products/fpodbc.shtml):

" A Robust, Cross Platform 4GL Database Development and Management System
with a new client-side ODBC interface which allows you interface directly
with ODBC data sources such as Access, Oracle, Sybase, SQL server, MySQL
and many more. Add the power of filePro processing to your ODBC
applications. fileProODBC includes all of the functionality of filePro Plus
5.0 and allows you to combine your current filePro applications with new
ODBC applications."

Please -show us- where they even purport to have server-side.  They don't.
It -explicitly- states client-side, and mention of server-side is
conspicious by its absence.  About the only thing they could do to make
this more plain is insert the word "only", which on the whole may be more
forthright but probably isn't a great marketing move.

> I understand that fP has a client ODBC connectivity only.  That's what 
> I've been complaining about.  That's what fpTech's sales told me.  No 
> misunderstanding there.  And it's a serious lack for any mature db product.

It seems like there's still a misunderstanding.  You seem to equate
"backend" with "server" magically.  There's no such implicit binding of
the technical definitions.  There may be a common expectation among people
conversant (and especially brought up with) modern database products, but
that's a perceived binding, not a technical one.  I might remind you that
fP functioned as a backend with -NO- networking for about 20 years.

That they only have client-side and not also server-side is an admitted
lack of a much-desired feature.  However, even I would dispute the use of
"mature" in that sentence, however.  "Modern," perhaps. filePro is mature,
but its design is not modern.  Its design predates ODBC by 13 years, as
ODBC is an MS standard that wasn't even announced until December 1991,
while fP was started as TEFC in 1978.

There are actually some really good reasons why server-side may actually
be next to impossible to back-port in.  For one thing, the "backend" isn't
always -running-.  That's kind of a prerequisite for being a server, ya
know?  It flat-out wasn't designed to run that way, and implementing it
is something that would take either a separate program (say, an fpodbcd
program that runs as a server and has most of the fP API built into it as
well), or a huge redesign of how the existing programs work.  Considering
there are four variants on the backends involved (d/rreport, d/rclerk), a
separate program makes the most sense.  It doesn't currently exist.

But they -don't- pretend to have it.  Nor do they pretend they're currently
implementing it.

So besides the facts that they told you the truth, and the feature isn't
implemented (and may never be), what was your original problem again?  I've
lost track of it in the apparent confusion between "backend" and "server",
which manifested itself as a confusion between client and server until you
actually showed you knew what you were talking about on the latter.

"I'm sorry, could you repeat the question?"

mark->