Start SQL server
-
Hello!
I am and old develloper of Access and want to start SQL server.
Please who can help giving me the steps to follow and any interrseting web site to help a newbee
Hugues
-
Welcome onboard!
Feel free to ask questions
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
Sorry, I have no suggestions other than online help or one of those 21 days titles for resources. SQL server is quite a bit different than access in ways that wont prevent you from writing code or creating dbs or objects that work, but work badly. I started in foxpro (dbase) and the transition for me was.. interesting.
Depending on the scope you will be working in you may need to understand different aspects of SQL.
General:
Don't get into a habit of writing SQL code in clients. Write stored procedures or UDFs that return tables and call them.
Learn how to use the SQL trace utility (profiler) before you go to serious production with a SQL solution. Meat and potatoes.
Turning the ShowQueryPlan on in ISQL is really nice, and is enough to get you started in watching for table scans, out-of-date statistics etc.
Querying:
The syntax is relatively straight forward, but I would definitely suggest reading up on indexes in online help, and using the proper join syntax instead of defining your joins in the where clause. Using old join syntax is bad. Also, avoid 'where x in (select...)' statements; outer join and check for null instead.
Procedures:
Don't touch begin tran - commit tran until you understand how to work with them. You will need to use them though IF you are modifying multiple tables where all or none of the changes need to occur, or when querying if you are adamant that the queried tables all must be precisely exact.
Learn to use the GOTO command. Quite handy for terminating an errored SP in my opinion.
Error trapping- Extroidonarily clumsy, but necessary in SQL. @@Error, as well as @@RowCount are reset after each select/insert/update/delete so you have to check each time.
Don't create 'god' stored procedures that do to much. Use the same sort of logic you use in creating an OOP heirarchy.
Just a few suggestions from a general view to give you food for thought.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply