GO is not a SQL statement. Rather, it is, by convention, a separator which tells the script processor that this is the end of a batch: it should send what it's read so far to the database, wait for a response, then proceed with the next set of statements up to the next GO (or end of file).
You should split your script at GO statements.
DoEvents: Generating unexpected recursion since 1991
You don't need the GO statement after declaring the cursor. By doing this, your first statement gets compiled into its own batch and is executed independently from the rest of the code. You don't want to do this. The one GO statement at the end is sufficient.
"No, his mind is not for rent
To any God or government" Tom Sawyer - Rush
Hi - I've tried, got the following error after removing GO after DECLARE CURSOR statement:
Message: ERROR [HY000] [MERANT][ODBC Sybase driver][SQL Server]DECLARE CURSOR must be the only statement in a query batch.
If I *need* cursor, what are my options? Can we have GO in stored proc? (wrap sql statement by stored proc?)
Hi every body!
I have a data base to store a large number of records and I want an Unique ID for each of them, so I used an UniqueIdentifier field, but the problem is when I delete a record, as you know, the identifier is not reordered automatically, so what should I do?
by the way, as I told I have many records to save. How can I prevent data from overflowing?
thanks for any help.
If using a .NET language, set the parameter object's Direction property to ParameterDirection.Output (or, if you're passing values in through this parameter as well, ParameterDirection.InputOutput). The parameter will then be set to this value once all resultsets have been read to the end.
DoEvents: Generating unexpected recursion since 1991
I have a database correupted when altering a field in db.
while it was altering i've killed the enterprise manager, then database returned to suspect mode we turned the db to emergency mode then we execute,
EXEC sp_resetstatus 'yourDBname';
ALTER DATABASE yourDBname SET EMERGENCY
ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ('yourDBname', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE yourDBname SET MULTI_USER
we get error that couldn't fix some corrupted pages
No real difference. You can express your inner joins in the WHERE clause if you wish (I believe in the early versions of SQL you had to), but your code will be easier to understand if you separate join conditions from the other conditions.
Is there anything special I should consider in a security model for an ASP.NET web site with a dedicated database, possibly on a shared server? I want to use Windows Authentication, but not the individual users.
1) Setup a Windows Group and grant that group login priviledges to your SQL Server instance.
2) Configure SQL Server to grant that group the needed priviledges for your database.
3) Create a Windows login and make that user a member of the windows group in step #1
4) Configure your IIS AppPool identity to be the Windows login you created in step #3
If you are working in a windows domain the group and user should be created at the domain level so that you can eventually separate the web server and database server.
I have an identity column of type int in my table and I need to reseed it when it reaches certain value.
I'm thinking of a trigger on insert that would check last generated identity value and reseed it if needed.
At the moment I believe I should use SCOPE_IDENTITY() and DBCC CHECKIDENT (table, reseed, initial_value) in CASE statement. If this is the case I need some help in putting things together otherwise I need a better solution.
Thanks for your reply. I think the solution you provided should work for me.
Just to clarify my problem.
Identity column is primary key in table that represents movement orders being processed at some moment in automated warehouse. So the table changes very dynamicaly and is generaly empty after each shift (if not it is due to crane or some other device malfunction).
The requirement is that this movement order ID should have values between e.g. 1000000 and 1999999 so when identity reaches critical value should be reseeded.
If this additional information makes any difference to your solution please let me know.
Just a warning that reseeding a primary key value can have some gotchas. As long as the table really is cleared out daily and there's no chance of the numbers being used w/in the same 24-48 hour period then you're probably fine. But if that primary key is being referenced elsewhere in other tables that don't get cleared out on the same schedules you're really in for some problems.
Any solution that depends on a specific constraint on identity keys is problematic. The value of the key should really be completely agnostic. It's purpose is for indexes and relations, not for business logic. That's not to say that you can't use an autonumber, but you may want to question why its being used and why it has to have this kind of constraint on it. And most importantly, if you are using the primary key value for these records elsewhere then you might want to use something else for the actual primary key value.
Here are some of the methods that most of the DBA's use to optimise the speed of MS SWL Server queries:
-Display the minimum number of fields in a query. Set criteria dependant fields that are not required in the dynaset to "not shown".
-Index all restriction based fields, all fields included in expressions, all sorted fields and all join fields.
-Use primary keys or unique indexes wherever possible.
-Use numeric rather than text primary keys.
-Use non blank unique fields.
-Avoid the use of IIf() function in queries.
-Avoid domain aggregate functions such as Dlookup().
-Make careful use of Between and Equal to, rather than > or < speeds up queries.
-Use fixed column headings in Crosstab queries.
-For reports based on queries use Portrait view in preference to Landscape and select Fast Laser
Printing to Yes (View,Options,Other Properties).
-Use Make table queries for running reports on static data. These are called snapshot reports.
-Use Count (*) rather than Count(Column).
-When creating restrictions on a joined column in one-to-many relationships, test out the comparative performance when placing the restriction on the "one" side or the "many" side. The "one" side is not always the fastest - the "many" may have markedly fewer records.
-Short table and field names run faster than long names.
-Normalise tables - join strategies execute more quickly on smaller tables.
-Denormalise tables - reduce the number of joins. Get the balance right between normalisation and denormalisation by experiment.
-Avoid the use of Distinct Row queries - Union queries do not need the distinct row feature as they are automatically return unique fields unless set to Union All.
You may visit the following link for more details about queyr optimization techniques.