OT: Filemaker 8

[Tyler]

On 2/6/06, Laura Brody <laura at hvcomputer.com> wrote:
>
> On Mon, 6 Feb 2006 12:20:36 -0700, Tyler <tyler.style at gmail.com> wrote:
>
> <snip>
> >
> > Hm.  Your interpretation of ODBC is a little skewed in this instance, I
> > think.
>
>         I believe that he was quite clear (see above).


Hm...  And I believe he wasn't (see previous).

> When people talk about ODBC and a database, it's usually as the
> > database acting as a server.  And filePro is *primarily* a database,
> with a
> > customizable app development available.  I'm not aware of any cases
> except
> > fP and text files where an ODBC connector is available and you can't
> > read/write to the source.  If it can communicate one way, why not two?
>
>         Because, from a programming standpoint, it is compairing apples
> and oranges. fP Tech would love to announce that they have ODBC server
> written, tested and ready for shipping tomorrow -- but it ain't gonna
> happen.... It is a big, hairy project, and I don't know when it
> will be added to the programmer's "to do" list. I know that I would
> rather be working on allowing larger screens in filePro than server
> side ODBC (and I know for a fact that there are a bunch of C source
> files which assume an 80 x 24 screen -- my code has some variables
> like MAX_WIDTH 80, etc. but there is a hell of a lot of code which
> doesn't). At least the screen size project is something that is
> just alot of work vs "how do we glue these very different databases
> together?".


I can't really say what the project scope would be like, I must admit.
However, write access is already there in fpCGI, which makes me wonder about
why it isn't in fpODBC.  But I'm happy to take your word for it that it's a
brutal task.  Personally, given the limited scope of fP as a back end, I
would prioritize integration over new features such as biometrics - with
easier integration, app issues like "I want a larger screen" go away as
people can use other development platforms for the front end if they like.
Once again, though, I'm not privy to fpTech corporate policies.

> In the case of text, it's because there's no easy way to limitfile access
> to one process at a time.  But filePro has that,sort of, nyet?
>
>         Huh?


I was just saying that ODBC to text files was scary because of access
control, but filePro already has basic file access controls in place.

> What it looks like from a developer's view is total lock-in to fP-only
> > applications for writing to records.  Personally I think it is either a
> > nasty marketing tactic or lazy programming, but admittedly I know very
> > little about filePro under the hood or corporately.
>
>         No marketing tactic. And I have to (virtually) take you
> out behind the woodshed for a sound thrashing for the "lazy
> programming" remark. Ken wrote the ODBC code. I've seen his
> code (and torture-tested it for 8 years). He may be a lazy
> husband at times, but never a lazy programmer. Once he begins
> a project, it will be designed and coded with excellence.
> Adding some enhancements to filePro is like trying to baptise
> a cat. It can be done, but the programmers are going to have
> to work for it. Nothing was easy with the client-side ODBC
> addition. It was a fight every single step of the way.


Thrash away.  I did preface my comment with the fact that I don't know much
about the mechanisms underlying fP, and as far as I know it's closed source,
so I never will.  But with almost every other DB under the sun (most of them
younger than filePro and many of them having started as hobbyist projects)
having full ODBC access, it does appear very odd from a developer
perspective that fP doesn't.  Hence my conclusion.

        BTW, until you *do* know a bit more about filePro the
> progam (and the company), you should make more of an effort
> to keep your comments to yourself.



How am I to learn, excatly, other than by posts like the one I made to this
list?  I'm hardly going to be able to wander down to fpTech and plunk myself
into corporate meetings and development sessions.  And I'm entitled to my
opinions, and to air what I see as a serious issue with the platform the
company I work for uses:  that I'm locked into using fpTech tools for
developing front ends for apps, aside from interactive web pages, and that
filePro app development is only geared to work with other filePro apps.  I
often have to go thru ludicrous contortions to integrate fP with other tools
such as credit card approval and shipping cost quotes that could be solved
in seconds with ODBC.

Just because an opinion is negative doesn't mean it shouldn't be aired
(despite what the Bush administration would like America to believe!).  If
it's wrong, people will argue with or correct me, and we all benefit.  If
it's true, then I have confirmation of its validity from others and we still
all benefit.

(as an aside, I thought the complete removal of all information provided in
the rather negatively slanted Wikipedia entry was rather draconian; most of
it was pretty factual, and the factual bits should have been at least
cleaned & kept as valid points instead of simply being excised with nothing
to replace them).

Tyler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.celestial.com/pipermail/filepro-list/attachments/20060206/7844783c/attachment.html