I have two team members who come from backgrounds that differ from what they're currently being asked to do: how can we encourage them to step up, develop their skills, and learn the new ways?
If you're talking about SQL code in itself, it is a relatively easy language to grasp and be productive with. I'd say she just needs to get a good book, read it and code SQL, and buckle down and start working with it.
As far as the encouragement goes, the desire to work hard to obtain something like this is intrinsic. But maybe you can explain how its not too monstrous of a language to learn. She must have some unjustified fear towards the language which you can alleviate.
Or if she's just plain old not interested in SQL she can 1) just learn it and use it or 2) find another job. That last statement is depending on whether or not this is a requirement for the position.
I suppose this depends on what you're doing with the SQL.
Surfer513 said that SQL is relatively easy to grasp and be productive with... but that really only applies to the basic CRUD stuff. Up until recently, I wasn't fully aware of all that SQL had to offer but a colleague of mine showed me some of the SQL he was working with for an advanced course in SQL Server 2008R2 (it was geomapping and some other stuff IIRC) and that can quickly get complicated/difficult.
So, if it's basic CRUD you're talking about then a good book, some practice and pair programming (or code reviews) with confidence building feedback should do the trick.
If you're working with some of the more complicated or esoteric bits, then a course or a certification might be called for. People usually feel confidence after a course, because they can say "I passed the course, I know x". Basically, a tangible badge of learning.
Make sure you have a test or development database that can be used as a sandbox. Oftentimes a fear of databases (or any component of a production system) is increased by the feeling that the least mistake will have catastrophic effects.
In the particular case of SQL databases you can show the engineer how to create test tables (
CREATE TABLE foo AS SELECT * FROM bar) that can be INSERTed into, DELETEd from and DROPped without consequence in the sandbox. Make sure that the sandbox has at least a subset of production data so the effects of things like indexes and full table scans can be experienced directly. Demonstrate the EXPLAIN statement to remove some of the mystery from what can seem like somewhat arbitrary and magical SQL incantations.
You might also point out that both COBOL and SQL date from the relative dark ages of the computer business with COBOL having the slight seniority but both far predating things like the personal computer and spreadsheets. Whether this is a comfort or not probably depends on the individual.
Just ask her some questions (maybe during a meeting) that can be answered by running simple SQL statements on a database, like "Sandra, how many customers do we have in New York right now?". Start it simple, it should encourage her to be able to answer that right away, so make sure it's on her level of knowledge. Make questions more difficult over time. (like what was our sales volume since we implemented the automatic payment system).
When you are sure she can do it, you can ask such questions in customer meetings as well. Customers are soooo impressed if you just hack something in a commandline tool and get the results and it may be a highly encouraging experience to her.