FreeTDS Development Group

[Brian Bruns <brian.bruns AT gmail.com>]

Vitaly,

You may also want to look at my SQL parser from MDB Tools (
mdbtools.sourceforge.net <http://mdbtools.sourceforge.net>) as a starting
point. It's a bit primative, but it's a working example.

Brian

2005/11/15, Зверев Виталий Борисович <VZverev AT genesis.spb.ru>:
>
> James,
> I would like to contribute parser into such strong project like FreeTDS if
> I only could parse its task properly ;).
> Okay, at first glance I should organize T-SQL placeholders knowledge and
> figure out their transformations and invariants.
> 1) DataType(Size,Scale,Nullable) transition for all predicates ?= , ? In
> () , ? <> any and so on
> 2) -//- mutations and constraints in buildin functions ( ... where sin(?)
> = ? And DATEADD ( ? , ?, ? ) = ? )
> 3) indirect type conversations (... where ?+'1'+'2' = ?), inline view
> attributes and stored proc parameters (by name and by position)
> The second question stuck me in longterm thought:
> What is *STANDARD* in prediction of placeholder metadata transformation?
> Really, if we are planning to mimic SQLDescribeParam, then mimic like which
> - Sybase, Ms, EasySoft, etc?
> Seems their SQLDescribeParam has a real implementation problems and
> deviations. As example, Easysoft for Sybase(Oracle driver has the same
> issue) http://www.mail-archive.com/dbi-users AT perl.org/msg25754.html and MS
> http://support.microsoft.com/default.aspx?scid=kb;en-us;273813 ,
> http://support.microsoft.com/default.aspx?scid=kb;en-us;325243.
> And third...
> May be T-Sql has grammar not fully LALR and my revelation about yacc is
> vain, but it should be investigated in more details. Any opinions would be
> covered. Has anybody viable reasons for using non LALR grammar?
>
> Sincerely yours.
> -------------------------------------------------------
> Vitaly Zverev, OCP DBA 8&8i
> Oracle E-Business Suite &
> Infiniband Linux Cluster Administrator
> Genesis Ltd., St.Petersburg, Russia
>
>
>
> > -----Original Message-----
> > From: freetds-bounces AT lists.ibiblio.org
> > [mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of
> > Lowden, James K
> > Sent: Monday, November 14, 2005 7:11 PM
> > To: FreeTDS Development Group
> > Subject: [freetds] parsing T-SQL with flex & yacc (was:
> > segfault in Perl'sEmail::Store when using freetds)
> >
> > > From: VZverev AT genesis.spb.ru
> > > Sent: Sunday, November 13, 2005 5:16 PM
> > >
> > > Hello James, I could try to do parser generator such as
> > 'bind param[i]
> > > is attribute of object..' with yacc style grammar in flex notation.
> > > What do you think about 'embedded SQL parser' (scn2.l) from
> > > http://examples.oreilly.com/lex/progs.zip, is it fair enough for
> > > starting point?
> >
> > Vitaly,
> >
> > That would be a great contribution. Every time I read about
> > yacc my eyes roll back in their sockets.
> >
> > Not that I didn't try. I found
> > ftp://ftp.ora.com/published/oreilly/nutshell/lexyacc/ , which
> > is from the O'Reilly nutshell book "lex & yacc" by Tony
> > Mason, John Levine, and Doug Brown
> > (http://www.oreilly.com/catalog/lex/index.html). Take your pick.
> >
> > Both files are probably copyrighted, even though the source
> > doesn't say so. Perhaps we could get permission, but we can
> > work that out later.
> > At least it's a starting point.
> >
> > Let me know what you decide.
> >
> > Regards,
> >
> > --jkl
> >
> > -----------------------------------------
> > The information contained in this transmission may be
> > privileged and confidential and is intended only for the use
> > of the person(s) named above. If you are not the intended
> > recipient, or an employee or agent responsible for delivering
> > this message to the intended recipient, any review,
> > dissemination, distribution or duplication of this
> > communication is strictly prohibited. If you are not the
> > intended recipient, please contact the sender immediately by
> > reply e-mail and destroy all copies of the original message.
> > Please note that we do not accept account orders and/or
> > instructions by e-mail, and therefore will not be responsible
> > for carrying out such orders and/or instructions. If you, as
> > the intended recipient of this message, the purpose of which
> > is to inform and update our clients, prospects and
> > consultants of developments relating to our services and
> > products, would not like to receive further e-mail
> > correspondence from the sender, please "reply" to the sender
> > indicating your wishes. In the U.S.: 1345 Avenue of the
> > Americas, New York, NY 10105.
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
> >
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>