FW: not good for fptech sales

[Doug Luurs]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com 
> [mailto:filepro-list-bounces at lists.celestial.com] On Behalf 
> Of Brian K. White
> Sent: Thursday, February 09, 2006 8:44 AM
> To: filepro-list at lists.celestial.com
> Subject: Re: FW: not good for fptech sales
> 
>  > There is a profound and distinct technical difference between an
> > application running on a server and servicing multiple users, and a 
> > server application that -must- be understood in order to have any 
> > meaningful dialogue on the subject.  If you want to go over 
> it, I'd be happy to revisit the topic.
> 
> It's really simple.
> I have no difficulty understanding that my copy of "less" is 
> not a server. It runs on a server, many people access it from 
> clients, it handles 
> centralized shared data, and never the less it doesn't look 
> smell or quack 
> like a server.
> 
> filePro is a database and a programming language. Simple as 
> that. Crying that it's not also a server is anyones right but 
> hardly productive. 
> And it's no ones obligation to listen or care.
> I wish my car was also a plane. And a boat. Such objects may 
> exist, but they 
> probly don't do simple driving on roads nearly as well as my 
> simple "it's 
> only a" car.
> The argument is just that silly. "People expect a 
> transportation device to 
> provide transportation!" Yeah whatever.
> An fp server would actually be more useful than helicopter blades and 
> pontoons on cars, but the argument that was put forth doesn't 
> hold water any 
> better than that.
> 
> And who knows, maybe it's a good thing that fp isn't the 
> universal adapter 
> from the IBM commercial. You know, the one that needs an 
> adapter to work in 
> Europe.
> I've always had the feeling that a lot of fp's speed is the 
> direct result of 
> the fact that a lot of it workings are not dynamic.
> So we have flat files and fixed numbers of indexes and fixed 
> numbers of menu 
> choices and etc.... and because of that that the code uses a 
> lot of fixed 
> tables and arrays and never has to worry about anything else 
> and so it's 
> fast. Just an unfounded theory.
> 
> Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
> +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
> filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com 
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 

I have to second Brian Comments .. Fp can be better, but as it stands,
theirs isn't a lot I can't get fp to do for me.

Fp is not a server .. It's a Solution .. And in my opinion, it's
A good one.  If it can't do something natively, I'll write code
To do it !  Case in Point .. The Reading and Decoding 2D Datamatrix, 
and PDF Barcodes.. Sounds hard, but very simple thing to do in fp.

Not a server?  So It's not Pretty GUI.  Who 'Really' cares. As
to hardly productive .. I wouldn't call 120+ people using our
filepro system 'Productive'.  Our currect system of files is
upwards of 200 files, most all tried to one or another, the last
time I looked, the largest file is 500000 records, and another
is up to 530 Meg.  And I am creating more systems daily. (Our plant
LOVES to dream up things.. Hehe)

What would I like to see in fp .. Export to a 'true' .XLS excel file.
OBC for unix <-> Windows Database connections, Updated SQL Program.
But I can live without them right now.

Would I switch to another database?  Yup .. Over my dead body.

This E-mail, including any attachments, may contain confidential information and is intended solely for use by the individual to whom it is addressed.  If you received this E-mail in error, please notify the sender, do not disclose its contents to others, and delete it from your system.  Any other use of this E-mail and/or attachments is prohibited.  This message is not meant to constitute an electronic signature or intent to contract electronically.