>>>>Or does anyone else get bleedin' tired of having to deal with people who: 1) don't know Fox and 2) haven't attempted to learn Fox yet think they can tell everyone what's wrong with Fox? If I hear one more contractor/consultant make the statement "Fox is ok to use until you decide to move the system into a REAL database" I'm gonna hurt something!
>>>>And the gods help us if we didn't hire these people to do a project in Fox!
>>>>
>>>>
>>>>Whew.....thanks....I'm feeling better now. I'll climb off my soapbox and let ya'll get back to real problems now.
>>>
>>>
>>>Add this one....
>>>
>>>I'm trying to get 3 new portables for me and my team. I asked for high end ones, suitable for applications development. The conversation went as follows:
>>>
>>>IS: What apps are you developing and what language/software do you need?
>>>Jen: Several apps in VFP 3.0, upgrading to VFP 5.0. We already own VFP.
>>>IS: You can't develop in VFP, it's not a supported product. You have to use Access. We can't support VFP.
>>>Jen: I don't need support. I have a team of 3 people with a combined 24+ years experience in xBASE language development, 8+ in VFP 3.0/5.0 alone.
>>>IS: You have to develop in Access -- it's company policy.
>>>Jen: Access will not handle the
>>> i) security requirements,
>>> ii) number of users,
>>> iii) volume of data and transactions.
>>> (gave them a bunch of numbers here)
>>>IS: [long pause] Oh, how come you are developing this level of apps?
>>>Jen: I inherited some of them written in 4D on the Mac, I converted the first to a crossplatform (Mac/PC) VFP app when you forced us to switch to PCs.
>>>IS: We didn't support 4D.
>>>Jen: I know........
>>>
>>>
>>>I'm getting the portables
>>>The IS "help" desk tech is still breathing
>>>
>>>Jen
>>I'm amazed....that they are still breathing that it. Not the situation. We have our own version.
>>
>>Management: We're a VB shop.
>>
>>Programmer: I thought we were a OOP shop
>>
>>Management: We are, we're a VB shop
>>
>>Programmer: But VB is object based, not object oriented
>>
>>Management: We're a VB shop
>>
>>Programmer: Ok, what's our back-end gonna be?
>>
>>Management: We're a VB shop
>>
>>Programmer: But VB doesn't 'do' data, what's our back-end gonna be?
>>
>>Management: We're a VB shop
>>
>>And so forth. 'course we only have 1 VB project in development. Everything else is VFP/Sybase, VFP, or MicroFocus COBOL.
>
>One more extension:
>Director of a department (not MIS): We want to develop new system...
>Programmer (me): No problem, we can proceed.
>Director: What language are you going to use?
>Programmer : Visual Foxpro
>Director: Why we cannot use Access?
>Programmer : Access is not good enough for such a system (mulituser, high-volume, etc.)
>Director: But you know, Visual Foxpro is not very good for us...
>Programmer : Why?
>Director: We were told this.
>Programmer : What exactly were you told?
>Director: that Foxpro can make standalone applications only.
>
>Hopefully, I could say and show here that they have already Foxpro apps which are apparently multi-user.
Ditto at one of our clients:
Client: We need a web enabled version of this application, what's it written in
Us: VFP
Client: That won't work on networks or our NT server.
Us: Sure it will, it was used for the EMail system you sent us your reply on. Remember the pharmacy care system's communication option?
Client: Are you sure, we access it from home over our internet supplier and we were told VFP couldn't do this.
Us: You bet, go check what you paid us for it. Also, you bought the source remember. The whole thing, standalone and network and WEB are the same application.
Client: Are you sure.
Our response was to remove the spash screens etc and let them see VFP starting etc. We replaced the stuff over the weekend.
Our lesson. They forget everthing once it is running smoothly. We 'hide' VFP to be more windows like. Maybe we should never hide VFP and let them see the toolbars and anything else that brands the applications all the time.
Gads