Thanks for the information. I know you are absolutely right; to create my own parser for such an open-ended language like SQL could become a massive hole for my time. Being honest, it's not really an avenue I have much time to devote going down.
I'm thinking I might be able to get away with grabbing a snapshot reader for an identified statement, then based on the caret position, I might be able to walk the token list to build a good enough picture to know about tables and fields at the current level. I say current level because in a sub-query, I should really know about the tables in the outer query.
I have had a search for a 3rd party parser I could wrap with the IParser interface (a great idea), but the best I could find is http://sqlparser.com/ However, I think this component, for $449 just doesn't cut the code completion requirement, since an incomplete SQL statement (actually fine as a picture for code completion) fails to parse at all.
Sorry to discuss 3rd party stuff in a post on your site; I wonder if you can recommend an alternative that would do this job?
Overall, code completion isn't critical, I have plenty of other more definite fish to fry, so this can go on the back burner.
Thanks for the guidance.