Showing posts with label environment. Show all posts
Showing posts with label environment. Show all posts

Thursday, March 29, 2012

Database Import/Export Question

I tried to export a database which includes tables and stored procedures from development environment to a production environment. For unknown reasons only the tables were copied whereas stored procedures were not copied and no error message shown what happened. Does anybody have a clue? I did the same export to an XP machine and it went through properly.How did you export the data? Did you use DTS?
Maybe you will find my previous post listing the steps I use to export objects to be helpful:http://forums.asp.net/1037418/showpost.aspx
|||Thanks. I got it. Don't know why the import/export said 100% complete but nothing showed up even I refreshed the stroed procedures in Enterprise Manager. And after a while (actually I went to pull someone to see the situation) the SP shown. Weird?|||

vljw8202 wrote:

Thanks. I got it. Don't know why theimport/export said 100% complete but nothing showed up even I refreshedthe stroed procedures in Enterprise Manager. And after a while(actually I went to pull someone to see the situation) the SPshown. Weird?


Enterprise Manager is often annoyingly unaware of schema changes. What I typically do is right-click on the server name and chooseRefresh, do the same for the Database node, the specific database, andthen the Tables node and any other node which should berefreshed. The new objects will then show up.
|||I see. Thanks for your advice.

Wednesday, March 21, 2012

Database Environment Naming Production -vs- Development

I have been looking for some documentation that would support or reject
my opinion on Production -vs- Development naming conventions. I
believe that each environment should be housed on separate servers with
identical names, access, users, stored procs...... If you either
agree or disagree with this methodology, I would appreciate your input.

TIA,
BillWith the same access? In most situations I don't want developers to
have the same access to production as they have in development. I
pretty much never want my users to have access to development either.

Other than that, I would agree. I think that every item that you have
to change between development and production is one more item that may
get you when moving changes from development to production.

In my environments I usually have a QA or testing server as well. This
one will more closely mirror production so that moving changes from QA
to production involves no manual changes at all - everything is
automated. This helps to ensure that no unforeseen bugs get moved into
production as the result of an errant upgrade script. The upgrade
scripts are run on QA, which is identical to production at the start
(often synchronized by a backup/restore unless the data is sensitive or
too large for the QA server). If the upgrade scripts work successfully
on QA and testing the changes is successful then confidence is pretty
high that they will work correctly in production.

HTH,
-Tom.|||I agree with Thomas. You cannot / should not test on a Dev server. So
you need at least three environments as near identical as possible.
Developers don't get access to Production except to troubleshoot a
problem that you can't repro elsewhere (unfortunately that happens).

--
David Portas
SQL Server MVP
--|||Thank you all for your responses.
And the access does change for Developers, we grant SELECT access to
view potential data issues and we also have Production control to move
both Databases and Interface methods (Executables and Web) from
Development to Production. There has been a desire to create a three
tier type environment, as we cycle out Production equipment I am keeping
it for the Development environments, so in another year or so I should
have the equipment for the 'QA' level.

Thanks again,
Bill

*** Sent via Developersdex http://www.developersdex.com ***|||Bill Willyerd (bwillyerd@.dshs.wa.gov) writes:
> I have been looking for some documentation that would support or reject
> my opinion on Production -vs- Development naming conventions. I
> believe that each environment should be housed on separate servers with
> identical names, access, users, stored procs...... If you either
> agree or disagree with this methodology, I would appreciate your input.

If we were do that in our shop, we would have to have a load of servers!

More generally, it depends on what your situation is. The above could
be a good idea for in-house applications, where there is exactly one
production server. (We develop a product, and we have one development
environment and one test environment for each customer and for each
version in production, test and development. That's a lot of databases.)

I would say that the key point is that you have separate servers.
Testing on a second database on the production machine can lead
unpleasant incidents, because test reveals a query with a poor query
plan.

Wether the database should have the same name? Of course, it helps,
but what if you need more than one testing environment? One of our
customers at one point had 3-4 test databases, all for our application.
I can reveal that they did not have four test servers. Thus, it is a
good idea to make it easy to switch database in the application.

As for the same stored procedures etc, this is best achieved by having
a version-control system as the definition of your system.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Hi

If your servers have identical names then they can not be on the same
network!!

John

"Bill Willyerd" <bwillyerd@.dshs.wa.gov> wrote in message
news:1114176300.794189.215830@.g14g2000cwa.googlegr oups.com...
>I have been looking for some documentation that would support or reject
> my opinion on Production -vs- Development naming conventions. I
> believe that each environment should be housed on separate servers with
> identical names, access, users, stored procs...... If you either
> agree or disagree with this methodology, I would appreciate your input.
> TIA,
> Bill

Friday, February 24, 2012

Database design help

trying to work on a new project, i need some ideas to setup this design model.
sql 2000 database and asp.
This is call center environment where agent bid on shift (schedules) base on most disireable to least, and it process base on seniority.well, let's see, you'll need an agent table, a shift table, and a bid table|||Don't forget the junction tables...

What you really should do is interview the users and the data source providers and model the business...

THEN create the logical data model after all the Entites and attributes have been defined....|||Identifying and introducing properties is an on-going process, but of course the earlier the better ;)|||Thanks guys
i will let you guys knows as it goes.
The biggest issue im looking at so far is to automate the process of assigning shitfs to agent base on seniority. Agents with higher seniorites get thier most rank shifts and so on. also there's avaibility of each shift, e.g shitA will only be given to 20 agents only and so on.
seniority is unique number already assigned to an agent. iwant to use store procedures or function to do that manupulation if possible, after all data's has been collected.|||Need to be careful with the "t" and "f" keys. It sounds like the agents queue up at the loo based on seniority, and only the first 20 agents get the best umm ... waste matter !!