Вбудовані оператори SQL, включаючи опис курсору, а також розділи опису виняткових ситуацій і змінних основної програми, повинні братися в дужки EXEC SQL і END EXEC. Опис курсору повинен зустрічатися текстуально раніше будь-якого оператора, що посилається на цей курсор. Всі змінні основної програми, які використовуються у вбудованих операторах SQL, повинні бути описанні в розділі, що передує опису змінних основної програми. При цьому синтаксис опису змінної відповідає синтаксису основної мови програмування, але імені змінної передує двокрапка.
В стандарті SQL визначені два способи взаємодії БД і прикладної програми, написаної на традиційній мові програмування. Перший спосіб полягає в тому, що всі оператори SQL, з якими може працювати дана прикладна програма, зібрані в один модуль і оформлені як процедури цього модуля. Для цього SQL має спеціальну підмову - мову модулей. При використанні такого способу взаємодії з БД прикладна програма містить виклики процедур модуля SQL з передачею їм фактичних параметрів і отриманням відповідних параметрів.
Другий спосіб полягає у використанні так званого вбудованого SQL, коли за допомогою спеціального синтаксису в програму на традиційній мові програмування вбудовуються оператори SQL так, ніби вони є операторами мови програмування. В цьому випадку, з точки зору прикладної програми, оператор SQL виконується "по місцю". Явна параметризація операторів SQL відстуня, але у вбудованих операторах SQL можуть використовуватися імена змінних основної програми, і за рахунок цього забезпечується зв'язок між прикладною програмою і СУБД.
Концептуально ці два засоби еквівалентні. Більш того, в стандарті встановлюються правила породження неявного модуля SQL по програмі з вбудованим SQL. Але в більшості реалізацій оператори SQL, які знаходяться в модулі SQL, і вбудовані оператори SQL обробляються по-різному. Модуль SQL майже завжди компілюється окремо від прикладної програми, в результаті чого породжується набір процедур «зберігання». Тобто коли використовується модуль SQL компіляція операторів SQL проводиться тільки один раз, і після цього відповідні процедури скільки завгодно раз можуть викликатися з прикладної програми.
На відміну від цього, для операторів SQL, вбудованих в прикладну програму, компіляція цих операторів зазвичай проводиться кожний раз при їх використанні (більш правильно сказати, при кожному першому використанні оператора при даному запуску прикладної програми).
Звичайно, користувачі не зобов'язані знати про ці технічні відмінності в обробці двох видів взаємодії з СУБД. Існують і такі системи, що виробляють одноразову компіляцію вбудованих операторів SQL і зберігають відкомпільований код. Але все-таки краще це зннати (наприклад, при компіляції оператора SQL безпосередньо перед його виконанням ймовірно отримати більш оптимальний план виконання оператора).
Наведемо деякі міркування за і проти кожного з цих двох засобів. При використанні мови модулей текст прикладної програми має менший розмір, взаємодія з СУБД більш локалізована за рахунок наявності явних параметрів виклика процедур. З іншого боку, для розуміння змісту поведінки прикладної програми потрібно одночасне читання двох текстів. Крім того, синтаксис модуля SQL може істотно відрізнятися в різних реалізаціях.
Вбудований SQL дає можливість зробити більш "самомістку" прикладну програму. Є більше підстав розраховувати на простоту переносу такої програми в середовище іншої СУБД, тому що стандарт вбудови більш-менш дотримується. Основним недоліком є деякий PL-подібний вигляд таких програм, незалежно від вибраної основної мови. І звичайно, потрібно враховувати зауваження, про які говорилося в попередніх абзацах.
Далі ми коротко опишемо мову модулей і правила вбудови у відповідності із стандартом SQL (ще раз відмітимо, що формально правила вбудови не є частиною стандарту).
