Ms Sql Server Technology Discussions

[karna11]

[quote name='DARLING...' timestamp='1353360653' post='1302825331']
painaa rendu tryu cheyyi vastadi
[/quote]
AA RENDU DARLIN

[deals2buy]

[quote name='9pardhu' timestamp='1353355745' post='1302824789']
last time evaro log file growth and truncation gurinchi adigaru

here are details:


You know there is always an issue - the log file growing very fast and big. If you have plenty of storage, then this might not be a problem for you. Anyway, this is no exception in the latest version of SQL, we still have to do something to truncate and shrink these files.

Implementation
[/quote]
[quote name='deals2buy' timestamp='1353355841' post='1302824802']
process kuda cheppu bhayya
[/quote]
[quote name='9pardhu' timestamp='1353361366' post='1302825410']
blogs .inkeysolutions. com/
2011/07/
shrinkfile-and-truncate-log-file-in-sql.
html
[/quote]
[quote name='9pardhu' timestamp='1353361392' post='1302825411']
remove spaces. i am unable to post because i dont have 200 posts
[/quote]


blogs.inkeysolutions.com/2011/07/shrinkfile-and-truncate-log-file-in-sql.html

thanku

[deals2buy]

[quote name='karna11' timestamp='1353361543' post='1302825424']
AA RENDU DARLIN
[/quote]
nenu last ga post chesina script try chey

[Desamudhuru]

baa 2 hrs nundi meeting so check cheyaleka poyanu thread ni

[deals2buy]

[quote name='deals2buy' timestamp='1353335797' post='1302822500']
declare @x float, @y float

set @x = 3.65
set @y = 3.75

--What values are returned by the following statements?
select 'x = ' + str(@x,10,1)
select 'y = ' + str(@y,10,1)


nee yavva okkadu kuda follow avvatam leda? answers cheppandi vayya deeniki with reason
[/quote]
[quote name='gundugadu' timestamp='1353338316' post='1302822644']
STR function returns char data from numeric data.

the ansers are x=3.7
y=3.8
[/quote]
[quote name='deals2buy' timestamp='1353338829' post='1302822680']
for the reply

kaani naaku x=3.6, y=3.8 vastunnay mama

anduke doubt vachindi
[/quote]
[quote name='gundugadu' timestamp='1353338968' post='1302822689']
ravadam ledu baaaa
x ki 3.6 ye vasthundi
and y di roof function chesthundi


donno why x is the same 3.6

nuvvemina catch chesthava leda ani ala x value thappu pettina


u rock reeeeeeeeeee
[/quote]
[quote name='deals2buy' timestamp='1353339268' post='1302822719']
emo ardham kaaledu..rendu same functions kadaa..aina y this result diff
[/quote]

declare @x float, @y float

set @x = 3.65
set @y = 3.75

--What values are returned by the following statements?
select 'x = ' + str(@x,10,1)
select 'y = ' + str(@y,10,1)


[b]Answer: [/b]C: x = 3.6 y = 3.8
[b]Explanation: [/b]Correct answer C: x = 3.6 y = 3.8
Rounding a number y to the nearest integer requires some tie-breaking rule for those cases when y is exactly half-way between two integers — that is, when the fraction part of y is exactly 0.5.

Ref: STR - [url="http://www.sqlservercentral.com/links/1427054/281515"]http://msdn.microsof...y/ms189527.aspx[/url]

[Desamudhuru]

Flat file nundi SQL server ki data copy chestunte qUOTES vostunayi column names ki em cheya mantaru baa ??

[Darling999]

[quote name='Desamudhuru' timestamp='1353424499' post='1302828837']
Flat file nundi SQL server ki data copy chestunte qUOTES vostunayi column names ki em cheya mantaru baa ??
[/quote]

text qualifier daggara " pettu or " pettu , nee data lo edi untey adi petti preview choodu [img]http://img837.imageshack.us/img837/4549/98269390.jpg[/img]

Ila

[Darling999]

[quote name='karna11' timestamp='1353361543' post='1302825424']
AA RENDU DARLIN
[/quote]

Alelooyaa

[Darling999]

Slowly changing Dimensions


[size=5][color=#000000][font=helvetica, verdana]The "Slowly Changing Dimension" problem is a common one particular to data warehousing. In a nutshell, this applies to cases where the attribute for a record varies over time. We give an example below:[/font][/color]
[color=#000000][font=helvetica, verdana]Christina is a customer with ABC Inc. She first lived in Chicago, Illinois. So, the original entry in the customer lookup table has the following record:[/font][/color]
[font=helvetica, verdana]Customer Key[/font] [font=helvetica, verdana]Name[/font] [font=helvetica, verdana]State[/font] [font=helvetica, verdana]1001[/font] [font=helvetica, verdana]Christina[/font] [font=helvetica, verdana]Illinois[/font]

[color=#000000][font=helvetica, verdana]At a later date, she moved to Los Angeles, California on January, 2003. How should ABC Inc. now modify its customer table to reflect this change? This is the "Slowly Changing Dimension" problem.[/font][/color]
[color=#000000][font=helvetica, verdana]There are in general three ways to solve this type of problem, and they are categorized as follows:[/font][/color]
[color=#000000][font=helvetica, verdana][url="http://www.1keydata.com/datawarehousing/slowly-changing-dimensions-type-1.html"]Type 1[/url]: The new record replaces the original record. No trace of the old record exists.[/font][/color]
[color=#000000][font=helvetica, verdana][url="http://www.1keydata.com/datawarehousing/slowly-changing-dimensions-type-2.html"]Type 2[/url]: A new record is added into the customer dimension table. Therefore, the customer is treated essentially as two people.[/font][/color]
[color=#000000][font=helvetica, verdana][url="http://www.1keydata.com/datawarehousing/slowly-changing-dimensions-type-3.html"]Type 3[/url]: The original record is modified to reflect the change.[/font][/color]
[color=#000000][font=helvetica, verdana]We next take a look at each of the scenarios and how the data model and the data looks like for each of them. Finally, we compare and contrast among the three alternatives.[/font][/color][/size]

[color=#000000][font=helvetica, verdana][size=5]-------------------------------------------------------[/size][/font][/color]

[size=4][color=#000000][font=helvetica, verdana]In Type 1 Slowly Changing Dimension, the new information simply overwrites the original information. In other words, no history is kept.[/font][/color][/size][color=#000000][font=helvetica, verdana][size=1]
[size=4]In our example, recall we originally have the following table:[/size][/size][/font][/color]
[size=4][font="helvetica,verdana"]Customer Key[/font][/size] [size=4][font="helvetica,verdana"]Name[/font][/size] [size=4][font="helvetica,verdana"]State[/font][/size] [size=4][font="helvetica,verdana"]1001[/font][/size] [size=4][font="helvetica,verdana"]Christina[/font][/size] [size=4][font="helvetica,verdana"]Illinois[/font][/size]
[color=#000000][font=helvetica, verdana][size=1]
[size=4]After Christina moved from Illinois to California, the new information replaces the new record, and we have the following table:[/size][/size][/font][/color]
[size=4][font="helvetica,verdana"]Customer Key[/font][/size] [size=4][font="helvetica,verdana"]Name[/font][/size] [size=4][font="helvetica,verdana"]State[/font][/size] [size=4][font="helvetica,verdana"]1001[/font][/size] [size=4][font="helvetica,verdana"]Christina[/font][/size] [size=4][font="helvetica,verdana"]California[/font][/size]
[color=#000000][font=helvetica, verdana][size=1]
[size=4][u]Advantages[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]- This is the easiest way to handle the Slowly Changing Dimension problem, since there is no need to keep track of the old information.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4][u]Disadvantages[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]- All history is lost. By applying this methodology, it is not possible to trace back in history. For example, in this case, the company would not be able to know that Christina lived in Illinois before.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4][u]Usage[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]About 50% of the time.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4][u]When to use Type 1[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]Type 1 slowly changing dimension should be used when it is not necessary for the data warehouse to keep track of historical changes.[/size][/size][/font][/color]
[color=#000000][font=helvetica, verdana][size=1]
[size=4]-------------------------------------------------------[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]In Type 2 Slowly Changing Dimension, a new record is added to the table to represent the new information. Therefore, both the original and the new record will be present. The newe record gets its own primary key.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]In our example, recall we originally have the following table:[/size][/size][/font][/color]
[size=4][font="helvetica,verdana"]Customer Key[/font][/size] [size=4][font="helvetica,verdana"]Name[/font][/size] [size=4][font="helvetica,verdana"]State[/font][/size] [size=4][font="helvetica,verdana"]1001[/font][/size] [size=4][font="helvetica,verdana"]Christina[/font][/size] [size=4][font="helvetica,verdana"]Illinois[/font][/size]
[color=#000000][font=helvetica, verdana][size=1]
[size=4]After Christina moved from Illinois to California, we add the new information as a new row into the table:[/size][/size][/font][/color]
[size=4][font="helvetica,verdana"]Customer Key[/font][/size] [size=4][font="helvetica,verdana"]Name[/font][/size] [size=4][font="helvetica,verdana"]State[/font][/size] [size=4][font="helvetica,verdana"]1001[/font][/size] [size=4][font="helvetica,verdana"]Christina[/font][/size] [size=4][font="helvetica,verdana"]Illinois[/font][/size] [size=4][font="helvetica,verdana"]1005[/font][/size] [size=4][font="helvetica,verdana"]Christina[/font][/size] [size=4][font="helvetica,verdana"]California[/font][/size]
[color=#000000][font=helvetica, verdana][size=1]
[size=4][u]Advantages[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]- This allows us to accurately keep all historical information.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4][u]Disadvantages[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]- This will cause the size of the table to grow fast. In cases where the number of rows for the table is very high to start with, storage and performance can become a concern.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]- This necessarily complicates the ETL process.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4][u]Usage[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]About 50% of the time.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4][u]When to use Type 2[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]Type 2 slowly changing dimension should be used when it is necessary for the data warehouse to track historical changes.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]-------------------------------------------------------[/size][/size][/font][/color]
[color=#000000][font=helvetica, verdana][size=1]
[size=4]In Type 3 Slowly Changing Dimension, there will be two columns to indicate the particular attribute of interest, one indicating the original value, and one indicating the current value. There will also be a column that indicates when the current value becomes active.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]In our example, recall we originally have the following table:[/size][/size][/font][/color]
[size=4][font="helvetica,verdana"]Customer Key[/font][/size] [size=4][font="helvetica,verdana"]Name[/font][/size] [size=4][font="helvetica,verdana"]State[/font][/size] [size=4][font="helvetica,verdana"]1001[/font][/size] [size=4][font="helvetica,verdana"]Christina[/font][/size] [size=4][font="helvetica,verdana"]Illinois[/font][/size]
[color=#000000][font=helvetica, verdana][size=1]
[size=4]To accommodate Type 3 Slowly Changing Dimension, we will now have the following columns:[/size][/size][/font][/color][list]
[*][size=4]Customer Key[/size]
[*][size=4]Name[/size]
[*][size=4]Original State[/size]
[*][size=4]Current State[/size]
[*][size=4]Effective Date[/size]
[/list][color=#000000][font=helvetica, verdana][size=1]
[size=4]After Christina moved from Illinois to California, the original information gets updated, and we have the following table (assuming the effective date of change is January 15, 2003):[/size][/size][/font][/color]
[size=4][font="helvetica,verdana"]Customer Key[/font][/size] [size=4][font="helvetica,verdana"]Name[/font][/size] [size=4][font="helvetica,verdana"]Original State[/font][/size] [size=4][font="helvetica,verdana"]Current State[/font][/size] [size=4][font="helvetica,verdana"]Effective Date[/font][/size] [size=4][font="helvetica,verdana"]1001[/font][/size] [size=4][font="helvetica,verdana"]Christina[/font][/size] [size=4][font="helvetica,verdana"]Illinois[/font][/size] [size=4][font="helvetica,verdana"]California[/font][/size] [size=4][font="helvetica,verdana"]15-JAN-2003[/font][/size]
[color=#000000][font=helvetica, verdana][size=1]
[size=4][u]Advantages[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]- This does not increase the size of the table, since new information is updated.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]- This allows us to keep some part of history.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4][u]Disadvantages[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]- Type 3 will not be able to keep all history where an attribute is changed more than once. For example, if Christina later moves to Texas on December 15, 2003, the California information will be lost.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4][u]Usage[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]Type 3 is rarely used in actual practice.[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4][u]When to use Type 3[/u]:[/size][/size][/font][/color][color=#000000][font=helvetica, verdana][size=1]
[size=4]Type III slowly changing dimension should only be used when it is necessary for the data warehouse to track historical changes, and when such changes will only occur for a finite number of time.[/size][/size][/font][/color]

[Desamudhuru]

[quote name='DARLING...' timestamp='1353428619' post='1302829335']

text qualifier daggara " pettu or " pettu , nee data lo edi untey adi petti preview choodu [img]http://img837.imageshack.us/img837/4549/98269390.jpg[/img]

Ila
[/quote]

thanks baa work finish iyindi but still thanks for your help baa...

[Desamudhuru]

[quote name='DARLING...' timestamp='1353428619' post='1302829335']

text qualifier daggara " pettu or " pettu , nee data lo edi untey adi petti preview choodu
[/quote]


Inkoka doubt baa.... Epudu nenu kotha table create cheatunna kabati create new ani OLEDB destination lo kotina. So apudu anni columns thisukundi Data Type annitiki Varchar petindi..... In future i'm comparing the table with another table.... for example oka column vundi Date ani danni compare chestuna from different table......

epudu nenu create chesina table Varchar------- nenu compare chese table Datatype ""Date"" vundi... apudu compare cheyadam kastam ithundi kada

[Darling999]

[quote name='Desamudhuru' timestamp='1353429296' post='1302829442']


Inkoka doubt baa.... Epudu nenu kotha table create cheatunna kabati create new ani OLEDB destination lo kotina. So apudu anni columns thisukundi Data Type annitiki Varchar petindi..... In future i'm comparing the table with another table.... for example oka column vundi Date ani danni compare chestuna from different table......

epudu nenu create chesina table Varchar------- nenu compare chese table Datatype ""Date"" vundi... apudu compare cheyadam kastam ithundi kada
[/quote]

create cehsey appudu script change cehyyi, datatypes future lo emuntaayoo avi icheyyi aah script lo simple

[deals2buy]

[quote name='Desamudhuru' timestamp='1353429296' post='1302829442']


Inkoka doubt baa.... Epudu nenu kotha table create cheatunna kabati create new ani OLEDB destination lo kotina. So apudu anni columns thisukundi Data Type annitiki Varchar petindi..... In future i'm comparing the table with another table.... for example oka column vundi Date ani danni compare chestuna from different table......

epudu nenu create chesina table Varchar------- nenu compare chese table Datatype ""Date"" vundi... apudu compare cheyadam kastam ithundi kada
[/quote]

if you are comparing dates with varchar then convert the datetype to varchar during comparison so that u need not change the datatypes of any objects (since they were modelled in such a way)

@DARLING: good post rey

[Darling999]

[quote name='Desamudhuru' timestamp='1353429116' post='1302829395']
thanks baa work finish iyindi but still thanks for your help baa...
[/quote]

No Problem rey be happy

[karna11]

[quote name='deals2buy' timestamp='1353361589' post='1302825431']
nenu last ga post chesina script try chey
[/quote]

SELECT * FROM SYS.objects WHERE type_desc = 'CHECK_CONSTRAINT' ILA KODA VASTHUNDHII BAA, IPPUDEE TELUSUKUNNA, CORRECT ME IF IM WRONG