So can you guys give me an idea if it is really hard to make a move, to upload the existing databases and to get used to it.
How long it takes?
I've been working on SQL server for about 18months, the last 6 months or so in a "proper" DBA role rather than "just" as a data administrator. If I'm honest, I wouldn't even try to apply for another DBA role yet as I'm only just starting to feel confident that I understand a lot of the basics covering what SQL server can do. Not least because I inherited an incredibly badly designed and implemented database that was effectively "hardcoded" by the application. If you tie yourself from day one into a similar pattern then getting to grips with SQL server is going to be a lot harder than it need be.
SQL server is not a client/server version of Access and just being good with Access isn't going to be enough to carry you into a SQL server developer/DBA role for any length of time.
In terms of moving an existing database application into SQL server then at a basic level if you're competent with Access then the fundamentals will be easy enough. Table design views etc are very similar, but you have a lot more flexibility at your disposal with SQL server. You will need to know ASAP the differences in Data types between Access and SQL server. Indexes, Stored Procedures and Views. I strongly recommend that you DON'T let your front end application send raw SQL to the database, especially if the development of that application relies on someone else (or the company having to spend extra money doing it), even as a short term measure. AS a DBA it's a lot easier for me to re-write a stored procedure or view to take into account changes I want to make than it is for me to convince the company to redesign their application.
If you're using SQL server 2000 then I do recommend getting ASAP a book like "Mastering SQL server 2000" by Sybex (we've no immediate plans to move to 2005, so I can't recommend any specific books no that). I've found it to be very useful. When I'm not doing proper work things (or Lurking here) then I'm working through that book covering the areas that I don't perhaps do a lot of on a day to day basis. In many cases, I've found a lot of those aspects suddenly are being used on a day to day basis once I've understood them.
in terms of sites.
http://www.sqlservercentral.com/ has proven useful and regularly publishes articles that are well worth reading even if it is just to think "wtf are they talking about, maybe I need to find out". There are some good "10 things a DBA should know" and "10 things that will get you sacked" type articles that you should really look at if you intend to cut the mustard as a SQL-server DBA.
http://www.sql-server-performance.com/default.asp is perhaps more useful once you've started to find your feet a bit
I also wouldn't even begin to think about moving your Access database into SQL server until you're comfortable with how you intend it to work. Putting your existing data tables into SQL server is straightforward enough, but what type of indexes do you intend to use? What security model are you going to implement when users login to your database? What are you going to use as your front end? If you are sticking with Access, which route are you going to take? can you simplify some of your existing code using, perhaps Triggers or UserDefined functions/Datatypes within SQL server and so on?
If you're keeping Access as a front end might you consider just exporting your tables into SQL server and linking them to Access to retain your existing code as much as possible, what considerations might this have to your existing code given the differences in how SQL server and Access handle some key information types?
