January 14, 2009 at 10:46 pm
Hi,
I am getting this below warning message when i create a new database using script.
"Cannot add rows to sys depends for the current object because it depends on the missing object. The object will still be created."
Can anybody tell me how can i carry off this?
---
January 14, 2009 at 11:24 pm
I will take an example to explain the warning.
Suposse you have a table - Employee and a SP AddEmployee. AddEmployee just inserts a record in Employee table and hence refers it.
Now, while running the script to create the database and the database objects if you create the SP AddEmployee before creating the table Employee you will get this warning (as Employee table doesn't exists at that moment).
If you create the Employee table before creating AddEmployee SP you won't get this error.
Hope this makes sense.
-Vikas Bindra
January 14, 2009 at 11:30 pm
This is really just a warning. It created the object, but it could not add the dependency records. It OK, everything should still work anyway.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
January 14, 2009 at 11:41 pm
(Sorry for typo I mentioned it as error in the last line)
I agree with RBarryYoung. Sometime later if you want to see that dependencies you won't get the results.
-Vikas Bindra
January 15, 2009 at 12:07 am
Thanks Vikas, RBarry for your quick reply.
I can understand now.
But is it possible to knock off that warning message also?
Because we are getting nearly 10 to 15 warning messages like the same while running the script.
---
January 15, 2009 at 12:29 am
Yes you can get away with these warnings. You will have to identity the objects that are generating these errors (as in the example AddEmployee SP) and then reorganize your script.
As the example of Employee and AddEmployee, you have move the script to create Employee table before the script to create AddEmployee SP.
-Vikas Bindra
January 15, 2009 at 12:32 am
You would have to reorder the script so that it creates the objects in the right order.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
January 15, 2009 at 3:25 am
vikas bindra (1/15/2009)
Yes you can get away with these warnings. You will have to identity the objects that are generating these errors (as in the example AddEmployee SP) and then reorganize your script.As the example of Employee and AddEmployee, you have move the script to create Employee table before the script to create AddEmployee SP.
Vikas,
Every time, i have to reorganize my script is a tedious work. Is there any other option which will resolve this issue Permanently?
---
January 15, 2009 at 4:13 am
Not one that I am aware of....
Usually the best practice is to create the objects in following order:
1. DB
2. Tables
3. Views
4. UDFs
5. SPs
But again, in Views, UDFs and SPs you have to take care of dependencies, as one view might be using another view.
And, why you want to reorganize the script everytime...just organize it once and save it for future references.
If the objects are deleted/added frquently (you are in development phase) then I would suggest you to have every object in a seperate file and automate the execution for deployment purpose.
Note, keeping objects in different files helps you in following manner:
1. Each object can be easily identified and updated in the source control.
2. adding and removing objects is much more easier.
3. Versioning is possible for every object.
and many more.....
-Vikas Bindra
January 15, 2009 at 7:58 am
Right, follow vikas's order of objects. The real problem comes in getting the Views ordered right (when they refer to each other) and the sProcs in the right order (same reason).
In theory you could have the same problem with UDF's but because of the performance hit, they do not usually call each other a lot.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply