"Prepare" in SQL Server through ODBC/ADO

Hi,
When using an interface like ADO or ODBC, there is a call named
"Prepare" which supposedly sent the statement to the server which in
turn should parse it, save the query plan and return a handle to the
client so subquent calls just refer to this handle/id and get faster
execution in batches... is this correct?
Well, my question is, when this Prepare or Parse is done, is there any
physical check being performed by SQL Server ? I mean, does it check
the column names, table existance, etc, or does it just check pure
syntax ?According to the ODBC 3.0 SDK, a SQLPrepare call to an ODBC driver sends the
statement to the data source for preparation and stores the returned access
plan identifier for later execution; or returns any errors including
SQLSTATE 42000 (Syntax error or access violation) and SQLSTATE 42S02 (Base
table or view not found). It also notes that some drivers do not return
errors after SQLPrepare is called, but rather when the statement is executed
later. So "SQLPrepare might appear to have succeeded when in fact it has
failed."
It would seem that you can't rely on a SQLPrepare call to return errors,
since not all drivers support that functionality via SQLPrepare.
Thanks,
Mike C.
<craigkenisston@.hotmail.com> wrote in message
news:1109726936.969442.224550@.o13g2000cwo.googlegroups.com...
> Hi,
> When using an interface like ADO or ODBC, there is a call named
> "Prepare" which supposedly sent the statement to the server which in
> turn should parse it, save the query plan and return a handle to the
> client so subquent calls just refer to this handle/id and get faster
> execution in batches... is this correct?
> Well, my question is, when this Prepare or Parse is done, is there any
> physical check being performed by SQL Server ? I mean, does it check
> the column names, table existance, etc, or does it just check pure
> syntax ?
>|||Thank you !!

"Phantom" Stored Procedures?

I have run into a problem where I cannot add a new stored
procedure to the master database because it supposedly
already exists, but I cannot see it in Enterprise
Manager, I cannot see it if I query the sysobjects table
directly for it, and I cannot drop it (I get a message
that nothing by that name exists in the catalog). I'd
like to know what is going on here with this catch-22
thing. It seems to be related to the fact that I moved
the master database over to this server from another one
using BACKUP/RESTORE. The originating server and the
destination server were named differently, and the master
database was moved from the C drive on the original
server to the D drive on the destination server when it
was restored.
I would be most grateful if someone could help me avoid a
rebuild of the master database, or worse, a re-install of
SQL Server altogether to solve this problem.
Mark> I have run into a problem where I cannot add a new stored
> procedure to the master database because it supposedly
> already exists, but I cannot see it in Enterprise
> Manager, I cannot see it if I query the sysobjects table
> directly for it, and I cannot drop it (I get a message
> that nothing by that name exists in the catalog).
Could you tell us the name of the stored procedure you are trying to add,
and why you are trying to add it to the master database?|||1) Are you using the sp_addextendedproc to add it?
2) Have you tried removing it first using sp_dropextendedproc?
3) and you're sure you are adding to master?
"Mark Schmidt" <Me@.spamthis.com> wrote in message
news:006d01c35127$e3ffc370$a101280a@.phx.gbl...
> >--Original Message--
> >> I have run into a problem where I cannot add a new
> stored
> >> procedure to the master database because it supposedly
> >> already exists, but I cannot see it in Enterprise
> >> Manager, I cannot see it if I query the sysobjects
> table
> >> directly for it, and I cannot drop it (I get a message
> >> that nothing by that name exists in the catalog).
> >
> >Could you tell us the name of the stored procedure you
> are trying to add,
> >and why you are trying to add it to the master database?
> >
> >
> >.
> >
> Well, this time it's actually an extended stored
> procedure that a consulting company gave me to effect
> some functionality in one of our applications that uses
> SQL Server. However, I had the same problem upgrading
> another of our servers to SP3a. That time it was system
> stored procedures that couldn't be dropped and re-added
> via the upgrade script because they were already there.
> Both scenarios involve the movement of the master
> database from an older server (which went out the door
> due to its lease expiration) to a newer one. I have
> noticed that seems to be the common denominator.