Printable View
This may be an obvious question to some but not me. I have SQL Server 2000 running on Windows Advanced Server 2000 on my machine. Lets say I develop the database on my machine. Now lets say I develop my app for the database and want to ship the software to the customer. How do I ship the SQL database. Its easy in Access, I just ship the mdb file. Is there an equivalent in SQL server.
Deployment of enterprise apps are different, lets face it i love access but access it not exactly the world´s most suited backend for enterprise systems.
when you choose to use SQL server and other uch DBMS you have to be willing to do a little more work
you will be faced with several problems that have to be solved.
1. Buying a copy of sql server for the deployment site. while you can have a Access application run on a machine with out Access this is not the case for sql server apps.
2. name and location of server. Given that you may not be able to influence the name of the server instance and its location on the network you have to build your app to cater for this. IF you are using the Data Environment to develop (as you should for sql apps) then life is easy, you only have to worry about the connection settings for one item. you can use registry entries that are stored during setup to know the location of the server. or configure an ini file with is location. You read this file on startup and adjust your connections
3. security. When developing your app you have to know how users will be authenticated. if you choose to use one user name on the sql server then please ensure that you develop your app using this user name so that you don´t have problems with the rights that this user needs. if users will authenticate via other means you also have to cater for that, or example are thy going to use their OS login, or do they all have individual loagins on the sql server. , if you then you have to assign roles so that access problems are worked out before you deploy, and with this kind of user access comes more problems with error handleing and stuff incase thy try to access something that their role does not allow.
PS: never use the sql server admin account for your apps.
now is your are workingon this project for a special company then get a whole of their current sql server environment, users, roles, machine locations and names, stuff like that. that will help in the plannig.
4. Deployment, that is not as hard as #3 but it is very important none the less. your database has to get to thier server. there are package and deployment apps out there that can help like Installshield that will allow you to request that a special sql script be run to create the database files. now in a network environment this is not all that easy and is not all that safe, you don´t want some secretary that thinks she can install the app on her own recreating your database with all 20 million customers go9ing down the drain. so hook the DBA up with your sql script which the Enterprise manager will kindly make for you with great ease. if you have data that you already have in the database that you need the hook in up with the backup of the database too ( enterprise manager again). let the work be done on the back end and then you deploy the setup.exes on the front end ( with no script for the secretary). If you want to get fancy you can proble the network for the sql server(port 14xx by default) on tcp/ip networks that way the secretary can install it for herself.
Wow, some great info there. Thanks for taking the time to respond.
I think what I read in your post was that there is some kind of packaging wizard in the enterprise manager that can build my database from a script once I have created it on my machine. That script is then run during the setup process at the customer site to create the database.
As for the other info, thanks for the tips.