Um... It depends? :) These are customer entered queries and vary based
on the end user and the customizations they have. It could be as
simple as WHERE inlist(SalesPerson,"Bob","Bill","Fred") OR it could be
something 12 lines long that pulls in criteria from multiple tables
each of those with their own criteria.

And by easy I meant simply that I would feel comfortable hacking
together something to handle inlist(x,1,2,3) and change it to "X in
(1,2,3)" it's the "rest" that worries me.

Having slept on it, I'm probably going to write something that
converts IN, checks for a list of "forbidden" words and then flags the
resulting updated query if it contains any of those words. This way I
can catch some of the low hanging fruit.

My hope is that if X% of queries don't contain foxpro specific
functions, and IN auto-conversions covers another X% of upgrades, and
auto-convert FunctionX (whatever it is...) gives us another X% of
upgrades... that this will result in a hopefully small number of saved
queries that are flagged for manual upgrading. (And not be so painful
in development that it still nets us saved time)


On Tue, Jul 21, 2009 at 1:54 PM, Ashley
Sheridan<> wrote:
> On Tue, 2009-07-21 at 13:46 -0400, Matt Neimeyer wrote:
>> Has anyone come across / written a script that will convert one
>> "flavor" or Dialect of SQL to another?
>> I need to convert Visual FoxPro 6.0 style WHERE clauses to MySQL.
>> For the most part the problems are converting VFP functions to the
>> equivalent SQL. For example, Visual FoxPro has a function inlist()
>> that is used like inlist(X,1,2,3) which converts to the MySQL query "X
>> IN (1,2,3)". That's easy enough (relatively speaking) but VFP also has
>> stuff like "EMPTY(X)" where any of Null, the Empty String (for Char),
>> 0000-00-00 (or the VFP equivalent anyways for dates), False (for
>> Boolean), 0 (for Numeric) are considered empty without needing to
>> know the data type. So that starts getting a lot more complex since I'd
>> need to check the data type of the field in the "right" table... to be
>> able to convert it to something like (X is null OR X="") or (X is null
>> OR x=0) etc...
>> These are for customer "stored" queries... I've already manually
>> converted "system" queries and I'm frustrated to the point of giving
>> up and adding a column "untested" and let the end user figure it out
>> but that seems bad from the standpoint of "lazy" and "poor customer
>> experience".
>> Thanks!
>> Matt
>> P.S. I'm also going to post this to the MySQL general list but my fear
>> is that they MIGHT say "We only know MySQL so we can't help you with
>> that other DBMS" I'm hoping that by posting here someone might say
>> "well it's not to MySQL but I ran script XYZ to convert my VFP to
>> PostgreSQL..." or similar.
> I'm not sure it's as easy as you think it might be. As you get more into
> the various flavours of SQL, you notice their little idiosyncrasies that
> only exist within that one particular language branch. As such, it's
> often a task best left to people to try and convert from one to the
> other, rather than leave it to a machine. How complex are the queries
> that you are trying to convert anyway?
> Thanks
> Ash

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to