Embedded SQL vs ODBC

  • Can someone tell me what is the difference and benefit between Embedded SQL and a call-level interface technology such as ODBC?

    Also can someone tell me a situation where it would be preferable to use static SQL over dynamic SQL?

  • To answer you second question first:

    Static sql (such as a stored procedure) has a pre-compiled execution plan and thus can be more efficient.

    To your first question:

    My take on this is that using ODBC or OLEDB with something like ADO gives you a level of encapsulation so that when you're programming you can make your front-end application not dependent on the backend database.

    In other words, the in theory idea was that you could write a frontend for multiple back end dbms's without having to change your front-end code. In practice this isn't really that practical as you usually end up using dbms-specific features at some level. Embedded SQL is like passing sql directly through to the dbms.

  • Embedded SQL should be, in general, a bit more performing in production, provided you've coded correctly.

    Reason is that you leave out all overhead functionality you do not need.

    However, as you probably guessed, you are kind of inventing the wheel again. There's a lot of stuff you have to think about when using embedded SQL. So, chances are that you'll end up with a beast to test, debug and maintain.

    By the way. The ODBC API is a relatively low level layer. Whereas OLEDB and ADO are a lot more high level. So if you need very high control over what exactly is happening, you might consider the ODBC API.

    If you only need general database features and performance is not highly critical (like in a real-time application), I would stick with something like ADO.

  • Thanks for the information. Really appreciate your comment and time.

  • Thanks for taking your time to answer my question.

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply