|
|
You can also user the SQL import Export wizard to transfer the data from one database to other database either table wise of bulk
|
|
|
|
|
Yeah that's me, I have sql server express installed on my local machine so I can test stuff without polluting the development server. So I have not needed it for ages, not trying anything new on a database level recently.
Well now I want to create a test database and I mislaid the blasted sa password and I don't have enough rights on the dammed thing. Apparently the only was is to re install the database Gggrrrr 
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Which is why you dont use SQL Authentication.
I feel your pain. Been there.
|
|
|
|
|
|
Now that I did not know, have 5 for he link, thank you, you have justified the rant...
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
hi every buddy
i hav e a problem to create new user in sql server 2008 r2
i create a user and my user created.
and i logined with this user succesfully. but when i want to create a new database in sqlserver authentication mode
i facing with this problem
"Create Database permission Denied in DataBase master.[error 262]"
thanks for any help.
|
|
|
|
|
You need dbo permission on the Master database (I think) to be able to create a database. Do some research on what permissions are available in SQL server it will be very enlightening.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
grant server role with sysadmin
|
|
|
|
|
HOW TO CONNECT DATABASE TO .NET PROJECT
|
|
|
|
|
Don't write in capital letters - looks like you're shouting. Try the manual[^].
|
|
|
|
|
Hi All,
Can someone enlighten me as to why you would need a default value of 0 on a tinyint field.
I'm not even sure if you do need to set it on all tinyint fields but I was told this by our previous DBA.
If the field "Allows Nulls", can it by default be left null without causing any problems?
Thanks,
JammoD
|
|
|
|
|
The same reason you'd want (need?) a default on any field - to save space.
You see, by making a field nullable it requires 1 extra byte of info per field per record to determine if the field is null.
|
|
|
|
|
I don't see saving 1 extra byte per field a relevant issue. I suspect it is an internal convention, default to 0 and the dba/developers/coder/us lazy bastards do not need to test for null values.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
If both of the following are true then it could be relevant.
1. High volume system.
2. Many columns of this type. (Really high volumes even a couple might be relevant.)
However since the vast majority of systems will never have both of these it isn't going to be relevant.
Mycroft Holmes wrote: and the dba/developers/coder/us lazy bastards do not need to test for null values.
And maybe a bit stupid too since zero and null are not necessarily the same thing.
|
|
|
|
|
jschell wrote: since zero and null are not necessarily the same thing
The is always a debating point, do we allow null to represent a value in a numeric field?
As I'm a lazy sod I disallow null in numeric field as my default position and until the business can convince me otherwise that is the way it is designed.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Thanks guys answers my question!
|
|
|
|
|
Can some one explain to me what a Staging area is ?
And I also want to know whether it is a database, a file, or something else altogether..?
|
|
|
|
|
Here are some answers: What is a staging area? Do we need it? What is the purpose of a staging area?[^].
Right now I'm using staging tables to temporarily store data imported from an outside source before pushing it to production so that it can be verified in isolation and altered as required.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
So you are using a staging area which is in between development and production phases. You said this staging area was a set of temporary tables. Can it be a whole separate database by itself? And if it is a database how do we make it temporary(as in what is its scope)?
And whatever operations you do on the staging area do you write the code for it or generate it using code generators?
PS: Don't mind the long question?
|
|
|
|
|
No, I said the data was temporarily stored: the tables are a permanent fixture and are used to transition that data before it gets exposed in the production tables. For my purposes it's okay for the tables to reside in the prod database but that might not suit you. There is no reason it can't be a wholly separate database: that's up to you and the requirements.
All of the code is either in stored procedures and/or c#. The usual scenario is that the tables are truncated and (in my case) filtered data is dumped into them and then other processes may work on them and then the data is moved to the primary tables.
Note that this is just how our solution works for us: it may not be right for you. Use anything like this with extreme caution, especially near production data.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
Aha that gives a lot of clarity....So these staging tables ...are they exact replica of production tables or do we have to follow some separate design principles to create them?
|
|
|
|
|
In my case they are straight copies of the production table but with all indexes, etc removed. Again, that suits my purpose. May not suit yours.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
We do it somewhat different to Mark, our staging table are exact replicas of the source data, this allows us to use Bulk Copy when loading the data. It also insures there are no errors in the Load part of the ELT process.
We then use stored procedures to do the transforms to the production format (these may also be staging tables in some solutions). The major benefit is that you are doing any transforms on a limited data set and it is easy to debug the procedure. It then becomes a simple matter to dump in the staging data to the production tables.
I find a well crafted ELT process leave any ETL application in the dust. There are some ETL apps that this may not apply to but the cost is extraordinary.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: our staging table are exact replicas of the source data, this allows us to use
Bulk Copy when loading the data. It also insures there are no errors in the Load
part of the ELT process.
I do the same thing, works great plus if there are any questions about the source data you already have a loaded copy in a table to query against.
Common sense is admitting there is cause and effect and that you can exert some control over what you understand.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
