There are more reasons to go with any Client Server / Mysql over VFP dbf /o
1 The ability to execute the program over the internet without having to
develop a web application as well as a desktop one.
2 There is no end to programmers and solutions who know and work with Mysql,
but the talent of VFP Programmers seems to be falling off a bit. Might as
well prepare clients that the industry is in somewhat agreement that client
server apps are more in line with the future, and you can help them get
there.
I am not saying that DBF are dead.. I use them all the time for local,
metadata and when I need to convert from something else to a report etc..
They really shine..
But overall, using client server with Mysql has been shown to me (by my
tests) to be overall faster deployment , less headaches and overall a
better user experience with VFP than just using dbf's over a network.
Bob Lee
----- Original Message -----
From: "MB Software Solutions" <vfpmcp (at) mbsoftwaresolutions D.O.T com>
To: <profoxtech@leafe.com>
Sent: Monday, May 29, 2006 6:28 PM
Subject: Re: Good selling point for VFP/MySQL dev work and development
timefor VFP/non-VFP backend integration
> Ted Roche wrote:
>
>> How often do you need to pack a MySQL database? How often do you need
>> to reindex? What's your strategy for recovering mangled memo fields?
>> Admittedly, all of these scenarios are less common with each version
>> as MSFT has made the DBF/DBC more robust, but it's still not (and
>> can't be) ACID compliant. Then there are security issues, encryption
>> questions, data access security...
>
> I know all that, but I don't lead my sales pitch with that...although
> perhaps I could and hence lean them towards MySQL? Still, what you've
> pointed out is valid but only a fraction of the time if it comes to happen
> at all. The VFP backend has been extremely reliable for me over the past
> few years. The only real incident I had recently was the Error 1550 and
> that hasn't happened much to me. My point is, by leading with those
> points, why would a customer who might not have the budget for the non-VFP
> backend ever want to choose VFP in that case? You've basically blown the
> confidence of using a VFP backend.
>
>>
>> I push the solution of MySQL on Linux for a robust database on a
>> secure and reliable platform. Why would you want to sell them less?
>
> Recall that I seem to have the cheapest f*ckin clients who want something
> for nothing, so I have to have options..."Just the Mercedes is for sale"
> is not the best idea. Sometimes offering the PT Loser as a cheaper
> alternative is a good revenue producer. <g>
>
>>> Wouldn't it be a good sell to use MySQL as the backend because it can
>>> run on any operating system (not just Windows)?
>>
>>
>> Not unless you want to support multiple platforms.
>
> But using a common GUI tool (like MySQLAdmin or the other flavors out
> there) would get away from you having to manage separate systems in a
> cumbersome way, right? Sure, if you're a command line jockey you'd have
> to know a few of the differences, but there's not that many that it'd be a
> PITA.
>
>>
>>> I'm thinking about offering the choice
>>> to clients (who care or are interested in the details) of using a VFP
>>> backend for a cheaper dev cost (because it'd take a little less time to
>>> develop/debug/deploy) or offering to use MySQL but at a higher charge
>>> since it will take a little longer to develop/debug/deploy.
>>
>>
>> That's interesting. I never considered it as a rate issue.I offered my
>> first few MySQL clients discounts as I was less familiar with the
>> platform and wanted to offer them some compensation in exchange for
>> riding the learning curve with me. And I wanted the gigs <s>.
>>
>> I would question whether there is a difference in development time.
>> Once you've mastered the tools, it shouldn't be. xCase or MySQL
>> Administrator and Query Browser give you lots of tools to work with.
>> You can debug in VFP, too.
>
> The only time difference would be in the Data Object/Access layer code as
> the UI and BizObj's (the way I design n-tier) wouldn't know nor care what
> backend you're using. (Hence why I said why when you get your Data code
> set up, you're good to go. I'm thinking that Andy Kramek's Tightline data
> classes would be a good framework to use for this.)
>
>>
>> Just this morning, I was hacking a WordPress blog (data storage in
>> MySQL, on a remote machine, via ssh) using VFP as my tool of choice
>> for fast scripting and nested cursor manipulation (de-duping multiple
>> redundant categories), and I didn't perceive a difference in how I go
>> about things. Then again, I've been doing the C/S thing since '98 or
>> so, so I'm used to have a design tool over here, a query tool over
>> there, and a VFP IDE in the middle somewhere.
>>
>>> Actually,
>>> when you guess your data access classes/mechanisms set up, it shouldn't
>>> be a whole lot of time difference.
>>
>>
>> And I don't charge my clients much in the way of setup and learning
>> new tools. Unless it's a tool they specifically require me to use that
>> doesn't fit into my long-term plans. So, setting up subversion or
>> CentOS or Request Tracker or MySQL or WordPress is my time and effort,
>> and once they are set up, I bill clients for my time as usual. When
>> the client requires their specific tool, they take a share of the cost
>> of setup.
>
> I see a difference between you and I: I seem to get clients who only want
> fixed prices whereas yours pay by the hour. That's a good start for
> another thread on its own: are you giving a fixed time quote as a "not to
> exceed" estimate and then charging by the hour towards that, or are they
> giving you carte blanche at a per/hour rate? I'd love to have the latter
> but these people aren't trusting for any it seems...they look at the
> latter as a "blank check" kind of thing.
>
>>
>>> Still, the non-VFP backend might
>>> take as long but wouldn't be quicker in terms of d/d/d imo. Do you
>>> think you could bring an app to fruition quicker with a non-VFP backend?
>>
>>
>> Nope. Not sure it's slower, either. Time to market seems to be a lot
>> more about communication, analysis, design, testing, specifications,
>> coordination, source control, change control, planning, meetings and
>> did I mention communication? Coding seems like the blocking factor
>> sometimes, as it's usually the gating factor at the end, but I don't
>> see it as that large a cost.
>>
> Right...the deployment and upgrade maintenance are a decent amount of time
> too.
>
> Great discussion points, Ted. Thanks.
> --
> Michael J. Babcock, MCP
> MB Software Solutions, LLC
> http://mbsoftwaresolutions.com
> http://fabmate.com
> "Work smarter, not harder, with MBSS custom software solutions!"
>
>
>
>
[excessive quoting removed by server]
©2006 Bob Lee |
|
