"MOVE" and "FIND" in SQL Server 2000

Our code is made in asp
We are moving the data from access to sql-server.
The recordset methods "MOVE" and "FIND" is now returning errormessages.
Anyone who can tell us what to use instead - or where to look it up ?
Best Regards
Jens GjerloevWhat error message are you getting ?|||For instance:
RS.Find(name=) & name
RS.Move(25)
"Jensgjerloev" wrote:

> Our code is made in asp
> We are moving the data from access to sql-server.
> The recordset methods "MOVE" and "FIND" is now returning errormessages.
> Anyone who can tell us what to use instead - or where to look it up ?
> Best Regards
> Jens Gjerloev|||You need to post a piece of your code, as well as your error messages.
Jensgjerloev wrote:
> Our code is made in asp
> We are moving the data from access to sql-server.
> The recordset methods "MOVE" and "FIND" is now returning errormessages.
> Anyone who can tell us what to use instead - or where to look it up ?
> Best Regards
> Jens Gjerloev|||Hello to Dave & Jens
Thanks for your reply.
Let me be honest: we have been in a state of panic during migration
from access to sql - so the mentioned error had NO relation fo MOVE and/or
FIND.
Sorry -
best regards
Jens Gjerloev
"Dave Markle" <"dma[remove_ZZ]ZZrkle" wrote:

> You need to post a piece of your code, as well as your error messages.
> Jensgjerloev wrote:
>

"GO" used in a stored procedure

I have a stored procedure in sql 2000 that requires steps to be fully
completed before moving to the next command in the procedure. I have
tried to place the word "GO" after each statement. When I create the
procedure then take a look at it through em, it only shows the code up
until the word "GO".

Example:
CREATE PROCEDURE mytest
as
create table mytable col1 varchar(5), col2 varchar(10)
GO
insert into mytable (col1, col2) values(abc, def)

All i see is:
CREATE PROCEDURE mytest
as
create table mytable col1 varchar(5), col2 varchar(10)
GO

I need to be 100% certain that the table has already been created
before trying to add records to it.

Is there any command that makes t-sql halt until the previous command
has finished?

Thanks,
DaveGO isn't a TSQL command. It marks the end of a batch in Query Analyzer and
therefore signals the end of a stored procedure definition in that batch, so
it cannot be part of an SP.

--
David Portas
SQL Server MVP
--|||Dave wrote:

> I have a stored procedure in sql 2000 that requires steps to be fully
> completed before moving to the next command in the procedure. I have
> tried to place the word "GO" after each statement. When I create the
> procedure then take a look at it through em, it only shows the code up
> until the word "GO".
> Example:
> CREATE PROCEDURE mytest
> as
> create table mytable col1 varchar(5), col2 varchar(10)
> GO
> insert into mytable (col1, col2) values(abc, def)
> All i see is:
> CREATE PROCEDURE mytest
> as
> create table mytable col1 varchar(5), col2 varchar(10)
> GO
>
> I need to be 100% certain that the table has already been created
> before trying to add records to it.
> Is there any command that makes t-sql halt until the previous command
> has finished?
> Thanks,
> Dave

You can be assured that the table will be created before the insert
statement is executed. Each command will be 100% finished and committed
before moving on to the next statement (unless you using transactions).

Zach|||
David,

Thanks for responding so quickly. I did read in several places that the
GO command does exactly what you have stated.

However, I still need to find a way to make sure that my code is
finished executing before moving to the next step within my stored
procedure.

The example I posted earlier was really dummied down from what I really
need to do. We have some procs here that are over 600 lines of code, and
most of them depend on the previous chunk of code to have completed
before they execute.

Any other ideas would be greatly appreciated.
Thanks,
Dave

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!|||Dave F wrote:

> David,
> Thanks for responding so quickly. I did read in several places that the
> GO command does exactly what you have stated.
> However, I still need to find a way to make sure that my code is
> finished executing before moving to the next step within my stored
> procedure.
> The example I posted earlier was really dummied down from what I really
> need to do. We have some procs here that are over 600 lines of code, and
> most of them depend on the previous chunk of code to have completed
> before they execute.
> Any other ideas would be greatly appreciated.
> Thanks,
> Dave
> *** Sent via Developersdex http://www.developersdex.com ***
> Don't just participate in USENET...get rewarded for it!

Like I said, SQL will ALWAYS complete a command before moving on to the
next one. What makes you think this doesn't already happen?

Zach|||[posted and mailed, please reply in news]

Dave (funkdm1@.yahoo.com) writes:
> Is there any command that makes t-sql halt until the previous command
> has finished?

To echo what Zach said: there is no command that causes T-SQL to continue
with the next command, before the previous has completed. So you
have no reason to worry.

--
Erland Sommarskog, SQL Server MVP, sommar@.algonet.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||This is a catch 22 situation.

Do you really need to create a new table each time you execute the stored proc?
If so, use temporary tables.

Otherwise empty your existing table before you insert rows.

Something seriously wrong

We have one database that is actually quite small, about 1.8GB. Upon moving
this db to SQL2K5 we get an error everytime we attempt to view the "Views"
folder. The error is:
Value cannot be null.
Parameter name: context (ObjectExplorer)
No more detail is available. I've gone back to the source database, removed
all views and repeated the process. Even with no views in the database we
get the same error when clicking on the "Views" folder in SQL Managment
Studio. All other db's have migrated fine.
NOW I figured I'd use the compare utility we have (We use Red Gates SQL
Compare) to compare the schema from that database to another server with an
old copy. This worked a few weeks ago, now it gives the error "Specified
cast is invalid" which sounds very likely to be related. This happens on
all servers running a copy of this database regardless of SQL Server
version. So at some point something bad was introduced. I'm just not sure
where to look, it sounds metadata related possibly but I'd hope there's some
other way of determining this other than going to a 6 week old backup and
hoping the issue isn't there.
Any help is greeted with humble thanks...we're really stuck.Tim,
Did you run the Upgrade Advisor on the DB before the move to 2005? This
might tell you something that does not migrate.
Chris Wood
"Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> wrote in message
news:uLgna8WaGHA.504@.TK2MSFTNGP03.phx.gbl...
> We have one database that is actually quite small, about 1.8GB. Upon
> moving this db to SQL2K5 we get an error everytime we attempt to view the
> "Views" folder. The error is:
> Value cannot be null.
> Parameter name: context (ObjectExplorer)
> No more detail is available. I've gone back to the source database,
> removed all views and repeated the process. Even with no views in the
> database we get the same error when clicking on the "Views" folder in SQL
> Managment Studio. All other db's have migrated fine.
> NOW I figured I'd use the compare utility we have (We use Red Gates SQL
> Compare) to compare the schema from that database to another server with
> an old copy. This worked a few weeks ago, now it gives the error
> "Specified cast is invalid" which sounds very likely to be related. This
> happens on all servers running a copy of this database regardless of SQL
> Server version. So at some point something bad was introduced. I'm just
> not sure where to look, it sounds metadata related possibly but I'd hope
> there's some other way of determining this other than going to a 6 week
> old backup and hoping the issue isn't there.
> Any help is greeted with humble thanks...we're really stuck.
>|||Yes I did. It only flagged a couple of sprocs with a syntax change (using
aliases in the order by clause)....
I might not have been clear. We encountered the issue during migration, BUT
then going back to our SQL 2000 servers currently in production this error
was encountered when using a specific tool. So, the issue is present BEFORE
migration.
"Chris Wood" <anonymous@.discussions.microsoft.com> wrote in message
news:eZTYegXaGHA.5004@.TK2MSFTNGP02.phx.gbl...
> Tim,
> Did you run the Upgrade Advisor on the DB before the move to 2005? This
> might tell you something that does not migrate.
> Chris Wood
> "Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> wrote in message
> news:uLgna8WaGHA.504@.TK2MSFTNGP03.phx.gbl...
>> We have one database that is actually quite small, about 1.8GB. Upon
>> moving this db to SQL2K5 we get an error everytime we attempt to view the
>> "Views" folder. The error is:
>> Value cannot be null.
>> Parameter name: context (ObjectExplorer)
>> No more detail is available. I've gone back to the source database,
>> removed all views and repeated the process. Even with no views in the
>> database we get the same error when clicking on the "Views" folder in SQL
>> Managment Studio. All other db's have migrated fine.
>> NOW I figured I'd use the compare utility we have (We use Red Gates SQL
>> Compare) to compare the schema from that database to another server with
>> an old copy. This worked a few weeks ago, now it gives the error
>> "Specified cast is invalid" which sounds very likely to be related. This
>> happens on all servers running a copy of this database regardless of SQL
>> Server version. So at some point something bad was introduced. I'm just
>> not sure where to look, it sounds metadata related possibly but I'd hope
>> there's some other way of determining this other than going to a 6 week
>> old backup and hoping the issue isn't there.
>> Any help is greeted with humble thanks...we're really stuck.
>