OT: Filemaker 8

[Laura Brody]

On Mon, 6 Feb 2006 12:20:36 -0700, Tyler <tyler.style at gmail.com> wrote:

> On 2/6/06, Kenneth Brody <kenbrody at bestweb.net> wrote:
>>
>> (Improper quoting corrected.)
>>
>> > > > 4. ODBC with read and write capabilities,
>> > > [...]
>> > >
>> > > This is not the first time I've heard someone say this.  Given that
>> > > the ODBC functionality in filePro has always been read/write, what
>> > > is it that has given you the impression that it's read-only?
>> >
>> > What gave ME that impression was calling up fpTech's sales people last
>> > year and asking.  I was told that no, you cannot use an ODBC connection
>> > to write to filePro records.  What's the point of having it if you can't
>> > use it to write to your data?  I mean, the fpCGI can, why not the ODBC?
>>
>> Either they misunderstood the question, or you misunderstood the answer.
>>
>> fileProODBC is, and always has been, read/write.  However, it is client
>> side only, and not an ODBC server.  In other words, filePro can connect
>> to ODBC servers, but ODBC clients cannot connect to filePro.
>>
>> --
>> KenBrody at BestWeb dot net

>
> Hm.  Your interpretation of ODBC is a little skewed in this instance, I
> think.

	I believe that he was quite clear (see above).

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

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

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

	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.

-- 
Laura Brody
+------------- Hudson Valley Computer Associates, Inc ----------+
| PO Box 859 120 Sixth Street    http://www.hvcomputer.com      |
| Verplanck, NY 10596-0859       Voice mail: (914) 739-5004     |
+------ PC repair locally, filePro programming globally --------+