Newbie Question. Please help.
I need to change the computer name on the sql server 2000.
What steps are involved after the computer name change.
Thanks a bunch.If you use a domain account that has restricted login ability, you will need to add that account to the new computername to be able to login in AD.
You will need to run sp_dropserver and sp_addserver (look in BOL for syntax)
If you created jobs while the PC was named the old name you will need to update the originating server name in sysjobs to your new PC name.
HTH
Showing posts with label newbie. Show all posts
Showing posts with label newbie. Show all posts
Sunday, March 25, 2012
Thursday, March 22, 2012
Computed column
I'm a newbie to SQL Server. I'm having a philosophical debate with myself
about the virtues/pitfalls of a computed column.
I was always under the impression you should not have a calculated field in
a table. Yet here I can enter a formula to create a client "FullName" field
with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in the table.
Does this mean this is now acceptable practice? Any gotchas lurking around
with this?
Consider it a "feature", to be used if you wish. You still have the option to present calculated
values through views, for instance. For special cases, calculated columns can be interesting, but
generally, I don't like to "litter" my table structures with calculated information.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself about the
> virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field in a table. Yet here I
> can enter a formula to create a client "FullName" field with the formula ([InsAnnLastName] + ', '
> + [InsAnnFirstName]) in the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around with this?
>
|||That denormalizes your database, and isn't considered good practice. You're
storing the same data twice, taking up twice the space... what advantage
are you trying to gain by doing this?
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself
> about the virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field
> in a table. Yet here I can enter a formula to create a client "FullName"
> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in
> the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around
> with this?
>
|||FWIW,
> ... You're storing the same data twice, taking up twice the space...
A calculated column doesn't consume disk space unless you explicitly create an index over the
calculated column. Unless of course you actually store the calculated *value* in a regular column
instead of defining a formula for the column.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Michael C#" <xyz@.yomomma.com> wrote in message news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
> That denormalizes your database, and isn't considered good practice. You're storing the same data
> twice, taking up twice the space... what advantage are you trying to gain by doing this?
> "Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>
|||At least it is a "documented" feature. It's those "undocumented features"
that drive me crazy.
To me a table stores data. What you do with the data belongs in Views,
Reports, etc.
However my coworkers wanted a way where we could have the client's full name
in the table. Ultimately it was wanted for use in Crystal Reports. So they
are happy campers now.
I'm a little less than happy as I fear I may have created a monster.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
> Consider it a "feature", to be used if you wish. You still have the option
> to present calculated values through views, for instance. For special
> cases, calculated columns can be interesting, but generally, I don't like
> to "litter" my table structures with calculated information.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Dkline" <Dkline001@.comcast.net> wrote in message
> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>
|||You're right. I mis-read and thought he was storing the results of the
calculation. I'm still trying to see the advantage of concatenating the
last and first names on the server in this fashion. It doesn't seem like it
would be all that useful...
Thx
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
> FWIW,
>
> A calculated column doesn't consume disk space unless you explicitly
> create an index over the calculated column. Unless of course you actually
> store the calculated *value* in a regular column instead of defining a
> formula for the column.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Michael C#" <xyz@.yomomma.com> wrote in message
> news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
>
|||Never mind, I just saw his follow-up message on why he's doing it that way.
Thx
"Michael C#" <xyz@.yomomma.com> wrote in message
news:%233$aSwcGFHA.4088@.TK2MSFTNGP09.phx.gbl...
> You're right. I mis-read and thought he was storing the results of the
> calculation. I'm still trying to see the advantage of concatenating the
> last and first names on the server in this fashion. It doesn't seem like
> it would be all that useful...
> Thx
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
>
|||Why not have your coworkers use a view instead?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx.gbl...
> At least it is a "documented" feature. It's those "undocumented features" that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views, Reports, etc.
> However my coworkers wanted a way where we could have the client's full name in the table.
> Ultimately it was wanted for use in Crystal Reports. So they are happy campers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
> news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>
|||P.S. - If one of your values in the computation is NULL, for instance if
[InsAnnLastName] for one record is NULL, the computed value of
([InsAnnLastName] + ', ' + [InsAnnFirstName]) will be NULL for that record.
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx.gbl...
> At least it is a "documented" feature. It's those "undocumented features"
> that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views,
> Reports, etc.
> However my coworkers wanted a way where we could have the client's full
> name in the table. Ultimately it was wanted for use in Crystal Reports. So
> they are happy campers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>
about the virtues/pitfalls of a computed column.
I was always under the impression you should not have a calculated field in
a table. Yet here I can enter a formula to create a client "FullName" field
with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in the table.
Does this mean this is now acceptable practice? Any gotchas lurking around
with this?
Consider it a "feature", to be used if you wish. You still have the option to present calculated
values through views, for instance. For special cases, calculated columns can be interesting, but
generally, I don't like to "litter" my table structures with calculated information.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself about the
> virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field in a table. Yet here I
> can enter a formula to create a client "FullName" field with the formula ([InsAnnLastName] + ', '
> + [InsAnnFirstName]) in the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around with this?
>
|||That denormalizes your database, and isn't considered good practice. You're
storing the same data twice, taking up twice the space... what advantage
are you trying to gain by doing this?
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself
> about the virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field
> in a table. Yet here I can enter a formula to create a client "FullName"
> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in
> the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around
> with this?
>
|||FWIW,
> ... You're storing the same data twice, taking up twice the space...
A calculated column doesn't consume disk space unless you explicitly create an index over the
calculated column. Unless of course you actually store the calculated *value* in a regular column
instead of defining a formula for the column.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Michael C#" <xyz@.yomomma.com> wrote in message news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
> That denormalizes your database, and isn't considered good practice. You're storing the same data
> twice, taking up twice the space... what advantage are you trying to gain by doing this?
> "Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>
|||At least it is a "documented" feature. It's those "undocumented features"
that drive me crazy.
To me a table stores data. What you do with the data belongs in Views,
Reports, etc.
However my coworkers wanted a way where we could have the client's full name
in the table. Ultimately it was wanted for use in Crystal Reports. So they
are happy campers now.
I'm a little less than happy as I fear I may have created a monster.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
> Consider it a "feature", to be used if you wish. You still have the option
> to present calculated values through views, for instance. For special
> cases, calculated columns can be interesting, but generally, I don't like
> to "litter" my table structures with calculated information.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Dkline" <Dkline001@.comcast.net> wrote in message
> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>
|||You're right. I mis-read and thought he was storing the results of the
calculation. I'm still trying to see the advantage of concatenating the
last and first names on the server in this fashion. It doesn't seem like it
would be all that useful...
Thx
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
> FWIW,
>
> A calculated column doesn't consume disk space unless you explicitly
> create an index over the calculated column. Unless of course you actually
> store the calculated *value* in a regular column instead of defining a
> formula for the column.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Michael C#" <xyz@.yomomma.com> wrote in message
> news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
>
|||Never mind, I just saw his follow-up message on why he's doing it that way.
Thx
"Michael C#" <xyz@.yomomma.com> wrote in message
news:%233$aSwcGFHA.4088@.TK2MSFTNGP09.phx.gbl...
> You're right. I mis-read and thought he was storing the results of the
> calculation. I'm still trying to see the advantage of concatenating the
> last and first names on the server in this fashion. It doesn't seem like
> it would be all that useful...
> Thx
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
>
|||Why not have your coworkers use a view instead?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx.gbl...
> At least it is a "documented" feature. It's those "undocumented features" that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views, Reports, etc.
> However my coworkers wanted a way where we could have the client's full name in the table.
> Ultimately it was wanted for use in Crystal Reports. So they are happy campers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
> news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>
|||P.S. - If one of your values in the computation is NULL, for instance if
[InsAnnLastName] for one record is NULL, the computed value of
([InsAnnLastName] + ', ' + [InsAnnFirstName]) will be NULL for that record.
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx.gbl...
> At least it is a "documented" feature. It's those "undocumented features"
> that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views,
> Reports, etc.
> However my coworkers wanted a way where we could have the client's full
> name in the table. Ultimately it was wanted for use in Crystal Reports. So
> they are happy campers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>
Computed column
I'm a newbie to SQL Server. I'm having a philosophical debate with myself
about the virtues/pitfalls of a computed column.
I was always under the impression you should not have a calculated field in
a table. Yet here I can enter a formula to create a client "FullName" field
with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in th
e table.
Does this mean this is now acceptable practice? Any gotchas lurking around
with this?Consider it a "feature", to be used if you wish. You still have the option t
o present calculated
values through views, for instance. For special cases, calculated columns ca
n be interesting, but
generally, I don't like to "litter" my table structures with calculated info
rmation.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.g
bl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself
about the
> virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field i
n a table. Yet here I
> can enter a formula to create a client "FullName" field with the formula (
[InsAnnLastName] + ', '
> + [InsAnnFirstName]) in the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around
with this?
>|||That denormalizes your database, and isn't considered good practice. You're
storing the same data twice, taking up twice the space... what advantage
are you trying to gain by doing this?
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself
> about the virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field
> in a table. Yet here I can enter a formula to create a client "FullName"
> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName
]) in
> the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around
> with this?
>|||FWIW,
> ... You're storing the same data twice, taking up twice the space...
A calculated column doesn't consume disk space unless you explicitly create
an index over the
calculated column. Unless of course you actually store the calculated *value
* in a regular column
instead of defining a formula for the column.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Michael C#" <xyz@.yomomma.com> wrote in message news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl..
.
> That denormalizes your database, and isn't considered good practice. You'
re storing the same data
> twice, taking up twice the space... what advantage are you trying to gain
by doing this?
> "Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.
tk2msftngp13.phx.gbl...
>|||At least it is a "documented" feature. It's those "undocumented features"
that drive me crazy.
To me a table stores data. What you do with the data belongs in Views,
Reports, etc.
However my coworkers wanted a way where we could have the client's full name
in the table. Ultimately it was wanted for use in Crystal Reports. So they
are happy campers now.
I'm a little less than happy as I fear I may have created a monster.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
> Consider it a "feature", to be used if you wish. You still have the option
> to present calculated values through views, for instance. For special
> cases, calculated columns can be interesting, but generally, I don't like
> to "litter" my table structures with calculated information.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Dkline" <Dkline001@.comcast.net> wrote in message
> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>|||You're right. I mis-read and thought he was storing the results of the
calculation. I'm still trying to see the advantage of concatenating the
last and first names on the server in this fashion. It doesn't seem like it
would be all that useful...
Thx
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
> FWIW,
>
> A calculated column doesn't consume disk space unless you explicitly
> create an index over the calculated column. Unless of course you actually
> store the calculated *value* in a regular column instead of defining a
> formula for the column.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Michael C#" <xyz@.yomomma.com> wrote in message
> news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
>|||Never mind, I just saw his follow-up message on why he's doing it that way.
Thx
"Michael C#" <xyz@.yomomma.com> wrote in message
news:%233$aSwcGFHA.4088@.TK2MSFTNGP09.phx.gbl...
> You're right. I mis-read and thought he was storing the results of the
> calculation. I'm still trying to see the advantage of concatenating the
> last and first names on the server in this fashion. It doesn't seem like
> it would be all that useful...
> Thx
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
>|||Why not have your coworkers use a view instead?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx
.gbl...
> At least it is a "documented" feature. It's those "undocumented features"
that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views, Rep
orts, etc.
> However my coworkers wanted a way where we could have the client's full na
me in the table.
> Ultimately it was wanted for use in Crystal Reports. So they are happy cam
pers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote i
n message
> news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>|||P.S. - If one of your values in the computation is NULL, for instance if
[InsAnnLastName] for one record is NULL, the computed value of
([InsAnnLastName] + ', ' + [InsAnnFirstName]) will be NULL for that
record.
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx.gbl...
> At least it is a "documented" feature. It's those "undocumented features"
> that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views,
> Reports, etc.
> However my coworkers wanted a way where we could have the client's full
> name in the table. Ultimately it was wanted for use in Crystal Reports. So
> they are happy campers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>
about the virtues/pitfalls of a computed column.
I was always under the impression you should not have a calculated field in
a table. Yet here I can enter a formula to create a client "FullName" field
with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in th
e table.
Does this mean this is now acceptable practice? Any gotchas lurking around
with this?Consider it a "feature", to be used if you wish. You still have the option t
o present calculated
values through views, for instance. For special cases, calculated columns ca
n be interesting, but
generally, I don't like to "litter" my table structures with calculated info
rmation.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.g
bl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself
about the
> virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field i
n a table. Yet here I
> can enter a formula to create a client "FullName" field with the formula (
[InsAnnLastName] + ', '
> + [InsAnnFirstName]) in the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around
with this?
>|||That denormalizes your database, and isn't considered good practice. You're
storing the same data twice, taking up twice the space... what advantage
are you trying to gain by doing this?
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself
> about the virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field
> in a table. Yet here I can enter a formula to create a client "FullName"
> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName
]) in
> the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around
> with this?
>|||FWIW,
> ... You're storing the same data twice, taking up twice the space...
A calculated column doesn't consume disk space unless you explicitly create
an index over the
calculated column. Unless of course you actually store the calculated *value
* in a regular column
instead of defining a formula for the column.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Michael C#" <xyz@.yomomma.com> wrote in message news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl..
.
> That denormalizes your database, and isn't considered good practice. You'
re storing the same data
> twice, taking up twice the space... what advantage are you trying to gain
by doing this?
> "Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.
tk2msftngp13.phx.gbl...
>|||At least it is a "documented" feature. It's those "undocumented features"
that drive me crazy.
To me a table stores data. What you do with the data belongs in Views,
Reports, etc.
However my coworkers wanted a way where we could have the client's full name
in the table. Ultimately it was wanted for use in Crystal Reports. So they
are happy campers now.
I'm a little less than happy as I fear I may have created a monster.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
> Consider it a "feature", to be used if you wish. You still have the option
> to present calculated values through views, for instance. For special
> cases, calculated columns can be interesting, but generally, I don't like
> to "litter" my table structures with calculated information.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Dkline" <Dkline001@.comcast.net> wrote in message
> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>|||You're right. I mis-read and thought he was storing the results of the
calculation. I'm still trying to see the advantage of concatenating the
last and first names on the server in this fashion. It doesn't seem like it
would be all that useful...
Thx
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
> FWIW,
>
> A calculated column doesn't consume disk space unless you explicitly
> create an index over the calculated column. Unless of course you actually
> store the calculated *value* in a regular column instead of defining a
> formula for the column.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Michael C#" <xyz@.yomomma.com> wrote in message
> news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
>|||Never mind, I just saw his follow-up message on why he's doing it that way.
Thx
"Michael C#" <xyz@.yomomma.com> wrote in message
news:%233$aSwcGFHA.4088@.TK2MSFTNGP09.phx.gbl...
> You're right. I mis-read and thought he was storing the results of the
> calculation. I'm still trying to see the advantage of concatenating the
> last and first names on the server in this fashion. It doesn't seem like
> it would be all that useful...
> Thx
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
>|||Why not have your coworkers use a view instead?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx
.gbl...
> At least it is a "documented" feature. It's those "undocumented features"
that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views, Rep
orts, etc.
> However my coworkers wanted a way where we could have the client's full na
me in the table.
> Ultimately it was wanted for use in Crystal Reports. So they are happy cam
pers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote i
n message
> news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>|||P.S. - If one of your values in the computation is NULL, for instance if
[InsAnnLastName] for one record is NULL, the computed value of
([InsAnnLastName] + ', ' + [InsAnnFirstName]) will be NULL for that
record.
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx.gbl...
> At least it is a "documented" feature. It's those "undocumented features"
> that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views,
> Reports, etc.
> However my coworkers wanted a way where we could have the client's full
> name in the table. Ultimately it was wanted for use in Crystal Reports. So
> they are happy campers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>
Computed column
I'm a newbie to SQL Server. I'm having a philosophical debate with myself
about the virtues/pitfalls of a computed column.
I was always under the impression you should not have a calculated field in
a table. Yet here I can enter a formula to create a client "FullName" field
with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in the table.
Does this mean this is now acceptable practice? Any gotchas lurking around
with this?Consider it a "feature", to be used if you wish. You still have the option to present calculated
values through views, for instance. For special cases, calculated columns can be interesting, but
generally, I don't like to "litter" my table structures with calculated information.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself about the
> virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field in a table. Yet here I
> can enter a formula to create a client "FullName" field with the formula ([InsAnnLastName] + ', '
> + [InsAnnFirstName]) in the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around with this?
>|||That denormalizes your database, and isn't considered good practice. You're
storing the same data twice, taking up twice the space... what advantage
are you trying to gain by doing this?
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself
> about the virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field
> in a table. Yet here I can enter a formula to create a client "FullName"
> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in
> the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around
> with this?
>|||FWIW,
> ... You're storing the same data twice, taking up twice the space...
A calculated column doesn't consume disk space unless you explicitly create an index over the
calculated column. Unless of course you actually store the calculated *value* in a regular column
instead of defining a formula for the column.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Michael C#" <xyz@.yomomma.com> wrote in message news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
> That denormalizes your database, and isn't considered good practice. You're storing the same data
> twice, taking up twice the space... what advantage are you trying to gain by doing this?
> "Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with myself about the
>> virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated field in a table. Yet here I
>> can enter a formula to create a client "FullName" field with the formula ([InsAnnLastName] + ', '
>> + [InsAnnFirstName]) in the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking around with this?
>|||At least it is a "documented" feature. It's those "undocumented features"
that drive me crazy.
To me a table stores data. What you do with the data belongs in Views,
Reports, etc.
However my coworkers wanted a way where we could have the client's full name
in the table. Ultimately it was wanted for use in Crystal Reports. So they
are happy campers now.
I'm a little less than happy as I fear I may have created a monster.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
> Consider it a "feature", to be used if you wish. You still have the option
> to present calculated values through views, for instance. For special
> cases, calculated columns can be interesting, but generally, I don't like
> to "litter" my table structures with calculated information.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Dkline" <Dkline001@.comcast.net> wrote in message
> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with myself
>> about the virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated field
>> in a table. Yet here I can enter a formula to create a client "FullName"
>> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in
>> the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking
>> around with this?
>|||You're right. I mis-read and thought he was storing the results of the
calculation. I'm still trying to see the advantage of concatenating the
last and first names on the server in this fashion. It doesn't seem like it
would be all that useful...
Thx
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
> FWIW,
>> ... You're storing the same data twice, taking up twice the space...
> A calculated column doesn't consume disk space unless you explicitly
> create an index over the calculated column. Unless of course you actually
> store the calculated *value* in a regular column instead of defining a
> formula for the column.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Michael C#" <xyz@.yomomma.com> wrote in message
> news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
>> That denormalizes your database, and isn't considered good practice.
>> You're storing the same data twice, taking up twice the space... what
>> advantage are you trying to gain by doing this?
>> "Dkline" <Dkline001@.comcast.net> wrote in message
>> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with
>> myself about the virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated field
>> in a table. Yet here I can enter a formula to create a client "FullName"
>> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in
>> the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking
>> around with this?
>>
>|||Never mind, I just saw his follow-up message on why he's doing it that way.
Thx
"Michael C#" <xyz@.yomomma.com> wrote in message
news:%233$aSwcGFHA.4088@.TK2MSFTNGP09.phx.gbl...
> You're right. I mis-read and thought he was storing the results of the
> calculation. I'm still trying to see the advantage of concatenating the
> last and first names on the server in this fashion. It doesn't seem like
> it would be all that useful...
> Thx
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
>> FWIW,
>> ... You're storing the same data twice, taking up twice the space...
>> A calculated column doesn't consume disk space unless you explicitly
>> create an index over the calculated column. Unless of course you actually
>> store the calculated *value* in a regular column instead of defining a
>> formula for the column.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "Michael C#" <xyz@.yomomma.com> wrote in message
>> news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
>> That denormalizes your database, and isn't considered good practice.
>> You're storing the same data twice, taking up twice the space... what
>> advantage are you trying to gain by doing this?
>> "Dkline" <Dkline001@.comcast.net> wrote in message
>> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with
>> myself about the virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated
>> field in a table. Yet here I can enter a formula to create a client
>> "FullName" field with the formula ([InsAnnLastName] + ', ' +
>> [InsAnnFirstName]) in the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking
>> around with this?
>>
>>
>|||Why not have your coworkers use a view instead?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx.gbl...
> At least it is a "documented" feature. It's those "undocumented features" that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views, Reports, etc.
> However my coworkers wanted a way where we could have the client's full name in the table.
> Ultimately it was wanted for use in Crystal Reports. So they are happy campers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
> news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>> Consider it a "feature", to be used if you wish. You still have the option to present calculated
>> values through views, for instance. For special cases, calculated columns can be interesting, but
>> generally, I don't like to "litter" my table structures with calculated information.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with myself about the
>> virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated field in a table. Yet here I
>> can enter a formula to create a client "FullName" field with the formula ([InsAnnLastName] + ',
>> ' + [InsAnnFirstName]) in the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking around with this?
>>
>|||P.S. - If one of your values in the computation is NULL, for instance if
[InsAnnLastName] for one record is NULL, the computed value of
([InsAnnLastName] + ', ' + [InsAnnFirstName]) will be NULL for that record.
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx.gbl...
> At least it is a "documented" feature. It's those "undocumented features"
> that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views,
> Reports, etc.
> However my coworkers wanted a way where we could have the client's full
> name in the table. Ultimately it was wanted for use in Crystal Reports. So
> they are happy campers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>> Consider it a "feature", to be used if you wish. You still have the
>> option to present calculated values through views, for instance. For
>> special cases, calculated columns can be interesting, but generally, I
>> don't like to "litter" my table structures with calculated information.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "Dkline" <Dkline001@.comcast.net> wrote in message
>> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with
>> myself about the virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated field
>> in a table. Yet here I can enter a formula to create a client "FullName"
>> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in
>> the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking
>> around with this?
>>
>|||Once again virtue is triumphant.
We settled on adding the FullName field to the table but it will not be a
computed column. Instead a small piece of VBA was added to the form and gets
the FirstName, LastName, etc., accounts for any NULLS, glues the pieces
together and puts the calculated value into the table.
It was that or do an update query. Either way - no calculated column.
Thank you both for your wisdom.
"Michael C#" <xyz@.yomomma.com> wrote in message
news:%23zm6rycGFHA.2588@.TK2MSFTNGP09.phx.gbl...
> Never mind, I just saw his follow-up message on why he's doing it that
> way.
> Thx
> "Michael C#" <xyz@.yomomma.com> wrote in message
> news:%233$aSwcGFHA.4088@.TK2MSFTNGP09.phx.gbl...
>> You're right. I mis-read and thought he was storing the results of the
>> calculation. I'm still trying to see the advantage of concatenating the
>> last and first names on the server in this fashion. It doesn't seem like
>> it would be all that useful...
>> Thx
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
>> in message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
>> FWIW,
>> ... You're storing the same data twice, taking up twice the space...
>> A calculated column doesn't consume disk space unless you explicitly
>> create an index over the calculated column. Unless of course you
>> actually store the calculated *value* in a regular column instead of
>> defining a formula for the column.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "Michael C#" <xyz@.yomomma.com> wrote in message
>> news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
>> That denormalizes your database, and isn't considered good practice.
>> You're storing the same data twice, taking up twice the space... what
>> advantage are you trying to gain by doing this?
>> "Dkline" <Dkline001@.comcast.net> wrote in message
>> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with
>> myself about the virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated
>> field in a table. Yet here I can enter a formula to create a client
>> "FullName" field with the formula ([InsAnnLastName] + ', ' +
>> [InsAnnFirstName]) in the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking
>> around with this?
>>
>>
>>
>
about the virtues/pitfalls of a computed column.
I was always under the impression you should not have a calculated field in
a table. Yet here I can enter a formula to create a client "FullName" field
with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in the table.
Does this mean this is now acceptable practice? Any gotchas lurking around
with this?Consider it a "feature", to be used if you wish. You still have the option to present calculated
values through views, for instance. For special cases, calculated columns can be interesting, but
generally, I don't like to "litter" my table structures with calculated information.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself about the
> virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field in a table. Yet here I
> can enter a formula to create a client "FullName" field with the formula ([InsAnnLastName] + ', '
> + [InsAnnFirstName]) in the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around with this?
>|||That denormalizes your database, and isn't considered good practice. You're
storing the same data twice, taking up twice the space... what advantage
are you trying to gain by doing this?
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
> I'm a newbie to SQL Server. I'm having a philosophical debate with myself
> about the virtues/pitfalls of a computed column.
> I was always under the impression you should not have a calculated field
> in a table. Yet here I can enter a formula to create a client "FullName"
> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in
> the table.
> Does this mean this is now acceptable practice? Any gotchas lurking around
> with this?
>|||FWIW,
> ... You're storing the same data twice, taking up twice the space...
A calculated column doesn't consume disk space unless you explicitly create an index over the
calculated column. Unless of course you actually store the calculated *value* in a regular column
instead of defining a formula for the column.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Michael C#" <xyz@.yomomma.com> wrote in message news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
> That denormalizes your database, and isn't considered good practice. You're storing the same data
> twice, taking up twice the space... what advantage are you trying to gain by doing this?
> "Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with myself about the
>> virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated field in a table. Yet here I
>> can enter a formula to create a client "FullName" field with the formula ([InsAnnLastName] + ', '
>> + [InsAnnFirstName]) in the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking around with this?
>|||At least it is a "documented" feature. It's those "undocumented features"
that drive me crazy.
To me a table stores data. What you do with the data belongs in Views,
Reports, etc.
However my coworkers wanted a way where we could have the client's full name
in the table. Ultimately it was wanted for use in Crystal Reports. So they
are happy campers now.
I'm a little less than happy as I fear I may have created a monster.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
> Consider it a "feature", to be used if you wish. You still have the option
> to present calculated values through views, for instance. For special
> cases, calculated columns can be interesting, but generally, I don't like
> to "litter" my table structures with calculated information.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Dkline" <Dkline001@.comcast.net> wrote in message
> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with myself
>> about the virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated field
>> in a table. Yet here I can enter a formula to create a client "FullName"
>> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in
>> the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking
>> around with this?
>|||You're right. I mis-read and thought he was storing the results of the
calculation. I'm still trying to see the advantage of concatenating the
last and first names on the server in this fashion. It doesn't seem like it
would be all that useful...
Thx
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
> FWIW,
>> ... You're storing the same data twice, taking up twice the space...
> A calculated column doesn't consume disk space unless you explicitly
> create an index over the calculated column. Unless of course you actually
> store the calculated *value* in a regular column instead of defining a
> formula for the column.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Michael C#" <xyz@.yomomma.com> wrote in message
> news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
>> That denormalizes your database, and isn't considered good practice.
>> You're storing the same data twice, taking up twice the space... what
>> advantage are you trying to gain by doing this?
>> "Dkline" <Dkline001@.comcast.net> wrote in message
>> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with
>> myself about the virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated field
>> in a table. Yet here I can enter a formula to create a client "FullName"
>> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in
>> the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking
>> around with this?
>>
>|||Never mind, I just saw his follow-up message on why he's doing it that way.
Thx
"Michael C#" <xyz@.yomomma.com> wrote in message
news:%233$aSwcGFHA.4088@.TK2MSFTNGP09.phx.gbl...
> You're right. I mis-read and thought he was storing the results of the
> calculation. I'm still trying to see the advantage of concatenating the
> last and first names on the server in this fashion. It doesn't seem like
> it would be all that useful...
> Thx
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
>> FWIW,
>> ... You're storing the same data twice, taking up twice the space...
>> A calculated column doesn't consume disk space unless you explicitly
>> create an index over the calculated column. Unless of course you actually
>> store the calculated *value* in a regular column instead of defining a
>> formula for the column.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "Michael C#" <xyz@.yomomma.com> wrote in message
>> news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
>> That denormalizes your database, and isn't considered good practice.
>> You're storing the same data twice, taking up twice the space... what
>> advantage are you trying to gain by doing this?
>> "Dkline" <Dkline001@.comcast.net> wrote in message
>> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with
>> myself about the virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated
>> field in a table. Yet here I can enter a formula to create a client
>> "FullName" field with the formula ([InsAnnLastName] + ', ' +
>> [InsAnnFirstName]) in the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking
>> around with this?
>>
>>
>|||Why not have your coworkers use a view instead?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Dkline" <Dkline001@.comcast.net> wrote in message news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx.gbl...
> At least it is a "documented" feature. It's those "undocumented features" that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views, Reports, etc.
> However my coworkers wanted a way where we could have the client's full name in the table.
> Ultimately it was wanted for use in Crystal Reports. So they are happy campers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in message
> news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>> Consider it a "feature", to be used if you wish. You still have the option to present calculated
>> values through views, for instance. For special cases, calculated columns can be interesting, but
>> generally, I don't like to "litter" my table structures with calculated information.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "Dkline" <Dkline001@.comcast.net> wrote in message news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with myself about the
>> virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated field in a table. Yet here I
>> can enter a formula to create a client "FullName" field with the formula ([InsAnnLastName] + ',
>> ' + [InsAnnFirstName]) in the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking around with this?
>>
>|||P.S. - If one of your values in the computation is NULL, for instance if
[InsAnnLastName] for one record is NULL, the computed value of
([InsAnnLastName] + ', ' + [InsAnnFirstName]) will be NULL for that record.
"Dkline" <Dkline001@.comcast.net> wrote in message
news:%23uz%23yQcGFHA.2524@.TK2MSFTNGP15.phx.gbl...
> At least it is a "documented" feature. It's those "undocumented features"
> that drive me crazy.
> To me a table stores data. What you do with the data belongs in Views,
> Reports, etc.
> However my coworkers wanted a way where we could have the client's full
> name in the table. Ultimately it was wanted for use in Crystal Reports. So
> they are happy campers now.
> I'm a little less than happy as I fear I may have created a monster.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
> in message news:usEebJcGFHA.2936@.TK2MSFTNGP15.phx.gbl...
>> Consider it a "feature", to be used if you wish. You still have the
>> option to present calculated values through views, for instance. For
>> special cases, calculated columns can be interesting, but generally, I
>> don't like to "litter" my table structures with calculated information.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "Dkline" <Dkline001@.comcast.net> wrote in message
>> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with
>> myself about the virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated field
>> in a table. Yet here I can enter a formula to create a client "FullName"
>> field with the formula ([InsAnnLastName] + ', ' + [InsAnnFirstName]) in
>> the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking
>> around with this?
>>
>|||Once again virtue is triumphant.
We settled on adding the FullName field to the table but it will not be a
computed column. Instead a small piece of VBA was added to the form and gets
the FirstName, LastName, etc., accounts for any NULLS, glues the pieces
together and puts the calculated value into the table.
It was that or do an update query. Either way - no calculated column.
Thank you both for your wisdom.
"Michael C#" <xyz@.yomomma.com> wrote in message
news:%23zm6rycGFHA.2588@.TK2MSFTNGP09.phx.gbl...
> Never mind, I just saw his follow-up message on why he's doing it that
> way.
> Thx
> "Michael C#" <xyz@.yomomma.com> wrote in message
> news:%233$aSwcGFHA.4088@.TK2MSFTNGP09.phx.gbl...
>> You're right. I mis-read and thought he was storing the results of the
>> calculation. I'm still trying to see the advantage of concatenating the
>> last and first names on the server in this fashion. It doesn't seem like
>> it would be all that useful...
>> Thx
>> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
>> in message news:uNhu$OcGFHA.2132@.TK2MSFTNGP14.phx.gbl...
>> FWIW,
>> ... You're storing the same data twice, taking up twice the space...
>> A calculated column doesn't consume disk space unless you explicitly
>> create an index over the calculated column. Unless of course you
>> actually store the calculated *value* in a regular column instead of
>> defining a formula for the column.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "Michael C#" <xyz@.yomomma.com> wrote in message
>> news:uHGO2LcGFHA.2752@.TK2MSFTNGP12.phx.gbl...
>> That denormalizes your database, and isn't considered good practice.
>> You're storing the same data twice, taking up twice the space... what
>> advantage are you trying to gain by doing this?
>> "Dkline" <Dkline001@.comcast.net> wrote in message
>> news:%23598C$bGFHA.3112@.tk2msftngp13.phx.gbl...
>> I'm a newbie to SQL Server. I'm having a philosophical debate with
>> myself about the virtues/pitfalls of a computed column.
>> I was always under the impression you should not have a calculated
>> field in a table. Yet here I can enter a formula to create a client
>> "FullName" field with the formula ([InsAnnLastName] + ', ' +
>> [InsAnnFirstName]) in the table.
>> Does this mean this is now acceptable practice? Any gotchas lurking
>> around with this?
>>
>>
>>
>
Tuesday, March 20, 2012
Compressing SQL Server Database
Newbie - SQL 2000. I have a database file 150 MB and my log file is 400 MB. Is there anyway I can compress the size of these files.
Thanks,If you don't need to take the backup of the Transaction Log:::
Take the full database backup(Recommended not Reqd)
go to Query Analyzer and
use [your database]
backup TRAN [your dbname] with no_log
once it's over then you can run:
dbcc SHRINKFILE([YOUR DBNAME_LOGFILENAME,TRUNCATEONLY)
and it will reduce the size of the Transaction Log
Thanks,If you don't need to take the backup of the Transaction Log:::
Take the full database backup(Recommended not Reqd)
go to Query Analyzer and
use [your database]
backup TRAN [your dbname] with no_log
once it's over then you can run:
dbcc SHRINKFILE([YOUR DBNAME_LOGFILENAME,TRUNCATEONLY)
and it will reduce the size of the Transaction Log
Sunday, February 19, 2012
Complete newbie to replication, have a question
We have had a server in LocationA for quite some time. The need arose
recently to have a server setup in LocationB due to some bandwidth issues.
LocationB was given a snapshot of the DB @. LocationA when it was first
setup. However, both machines will need to have the same data as both are
used in a production environment. I will probably want to do this nightly.
I have read a lot of posts and webistes, but still am semi in the dark.
About the only thing i've figured out (i think) is that I will need to do
some sort of merge replicaiton.
What do I need to do to get started, a link to a HOW TO for a smiliar setup
would be great. I have read a bit and some mention having a 3rd server, do
i need a 3rd server as the final merged server? I guess more importantly is
a 3rd server an optimal solution?
Any help would be greatly appreciated.
Forgot to mention, I am running SQL Server 2000 on both servers.
"Lucas Graf" <lgraf2000@.comcast.net> wrote in message
news:OjZ0E0bQGHA.5296@.TK2MSFTNGP09.phx.gbl...
> We have had a server in LocationA for quite some time. The need arose
> recently to have a server setup in LocationB due to some bandwidth issues.
> LocationB was given a snapshot of the DB @. LocationA when it was first
> setup. However, both machines will need to have the same data as both are
> used in a production environment. I will probably want to do this
> nightly.
> I have read a lot of posts and webistes, but still am semi in the dark.
> About the only thing i've figured out (i think) is that I will need to do
> some sort of merge replicaiton.
> What do I need to do to get started, a link to a HOW TO for a smiliar
> setup would be great. I have read a bit and some mention having a 3rd
> server, do i need a 3rd server as the final merged server? I guess more
> importantly is a 3rd server an optimal solution?
> Any help would be greatly appreciated.
>
|||In merge replication you will have Distributor, Publisher and Subscriber.
They are different roles for a replication setup but they can be on the same
physical machine. I think the 3rd server you mentioned is distributor. You
can setup the distributor on the same server with the publisher, so you
don't need a third machine.
Yi Chen
"Lucas Graf" <lgraf2000@.comcast.net> wrote in message
news:OjZ0E0bQGHA.5296@.TK2MSFTNGP09.phx.gbl...
> We have had a server in LocationA for quite some time. The need arose
> recently to have a server setup in LocationB due to some bandwidth issues.
> LocationB was given a snapshot of the DB @. LocationA when it was first
> setup. However, both machines will need to have the same data as both are
> used in a production environment. I will probably want to do this
> nightly.
> I have read a lot of posts and webistes, but still am semi in the dark.
> About the only thing i've figured out (i think) is that I will need to do
> some sort of merge replicaiton.
> What do I need to do to get started, a link to a HOW TO for a smiliar
> setup would be great. I have read a bit and some mention having a 3rd
> server, do i need a 3rd server as the final merged server? I guess more
> importantly is a 3rd server an optimal solution?
> Any help would be greatly appreciated.
>
|||Ok. That makes sense.
I have been messing around trying to set it up today, and am still lost.
Currently the 2 servers are out of sync. Both have data the other doesn't.
What do I need to do to get them both to have the same data now, and then
keep them replciating from here on out?
"Yi Chen [MSFT]" <yiche@.online.microsoft.com> wrote in message
news:%23o7jSucQGHA.1204@.TK2MSFTNGP12.phx.gbl...
> In merge replication you will have Distributor, Publisher and Subscriber.
> They are different roles for a replication setup but they can be on the
> same physical machine. I think the 3rd server you mentioned is
> distributor. You can setup the distributor on the same server with the
> publisher, so you don't need a third machine.
> Yi Chen
> "Lucas Graf" <lgraf2000@.comcast.net> wrote in message
> news:OjZ0E0bQGHA.5296@.TK2MSFTNGP09.phx.gbl...
>
|||Lucas Graf wrote:
> We have had a server in LocationA for quite some time. The need arose
> recently to have a server setup in LocationB due to some bandwidth issues.
> LocationB was given a snapshot of the DB @. LocationA when it was first
> setup. However, both machines will need to have the same data as both are
> used in a production environment. I will probably want to do this nightly.
> I have read a lot of posts and webistes, but still am semi in the dark.
> About the only thing i've figured out (i think) is that I will need to do
> some sort of merge replicaiton.
> What do I need to do to get started, a link to a HOW TO for a smiliar setup
> would be great. I have read a bit and some mention having a 3rd server, do
> i need a 3rd server as the final merged server? I guess more importantly is
> a 3rd server an optimal solution?
> Any help would be greatly appreciated.
|||Lucas,
presumably you have initialized the subscriber and are using merge
replication? If so, you just need to synchronize the subscriber to have the
data merged. You'll need to consider who should win conflicts (publisher by
default) and if conflicts should be allowed (filtering).
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Ok.
I got this far and was tentative on going further. I will keep trucking and
see what else may come up that causes issues. Thanks for the help so far, I
hope to report back a positive experience.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23ogHO4uQGHA.2628@.TK2MSFTNGP15.phx.gbl...
> Lucas,
> presumably you have initialized the subscriber and are using merge
> replication? If so, you just need to synchronize the subscriber to have
> the data merged. You'll need to consider who should win conflicts
> (publisher by default) and if conflicts should be allowed (filtering).
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||I guess I am still confused w/the whole publisher/distributor thing.
Since I want both servers to merge both of their data are they both set to
publishers and distributors? Or is only 1 a publisher and both distributors
and subscribers?
So confused..
"Lucas Graf" <lgraf2000@.comcast.net> wrote in message
news:Ob$pMuzQGHA.2436@.TK2MSFTNGP11.phx.gbl...
> Ok.
> I got this far and was tentative on going further. I will keep trucking
> and see what else may come up that causes issues. Thanks for the help so
> far, I hope to report back a positive experience.
>
> "Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
> news:%23ogHO4uQGHA.2628@.TK2MSFTNGP15.phx.gbl...
>
|||Ok.
ServerA
I have set him to a Distributor, Publisher and set the Database i want to
publish to the other server as the "push" datatabase. All seems good on
ServerA.
ServerB
Not sure what to do here so its data gets pushed to ServerA to be merged
there as well. Everything I try i end up getting the error "You cannot
create a merge replicaion in database xxxc. The database contains one or
more merge subscritptions that are anonymous or that use the Priority of the
Publisher when resolving conflicts."
"Lucas Graf" <lgraf@.nvidia.com> wrote in message
news:uSQuaI8QGHA.5552@.TK2MSFTNGP14.phx.gbl...
>I guess I am still confused w/the whole publisher/distributor thing.
> Since I want both servers to merge both of their data are they both set to
> publishers and distributors? Or is only 1 a publisher and both
> distributors and subscribers?
> So confused..
>
> "Lucas Graf" <lgraf2000@.comcast.net> wrote in message
> news:Ob$pMuzQGHA.2436@.TK2MSFTNGP11.phx.gbl...
>
|||Maybe Bidirectional Transactional Replication is more what I am looking for?
"Lucas Graf" <lgraf@.nvidia.com> wrote in message
news:uSQuaI8QGHA.5552@.TK2MSFTNGP14.phx.gbl...
>I guess I am still confused w/the whole publisher/distributor thing.
> Since I want both servers to merge both of their data are they both set to
> publishers and distributors? Or is only 1 a publisher and both
> distributors and subscribers?
> So confused..
>
> "Lucas Graf" <lgraf2000@.comcast.net> wrote in message
> news:Ob$pMuzQGHA.2436@.TK2MSFTNGP11.phx.gbl...
>
recently to have a server setup in LocationB due to some bandwidth issues.
LocationB was given a snapshot of the DB @. LocationA when it was first
setup. However, both machines will need to have the same data as both are
used in a production environment. I will probably want to do this nightly.
I have read a lot of posts and webistes, but still am semi in the dark.
About the only thing i've figured out (i think) is that I will need to do
some sort of merge replicaiton.
What do I need to do to get started, a link to a HOW TO for a smiliar setup
would be great. I have read a bit and some mention having a 3rd server, do
i need a 3rd server as the final merged server? I guess more importantly is
a 3rd server an optimal solution?
Any help would be greatly appreciated.
Forgot to mention, I am running SQL Server 2000 on both servers.
"Lucas Graf" <lgraf2000@.comcast.net> wrote in message
news:OjZ0E0bQGHA.5296@.TK2MSFTNGP09.phx.gbl...
> We have had a server in LocationA for quite some time. The need arose
> recently to have a server setup in LocationB due to some bandwidth issues.
> LocationB was given a snapshot of the DB @. LocationA when it was first
> setup. However, both machines will need to have the same data as both are
> used in a production environment. I will probably want to do this
> nightly.
> I have read a lot of posts and webistes, but still am semi in the dark.
> About the only thing i've figured out (i think) is that I will need to do
> some sort of merge replicaiton.
> What do I need to do to get started, a link to a HOW TO for a smiliar
> setup would be great. I have read a bit and some mention having a 3rd
> server, do i need a 3rd server as the final merged server? I guess more
> importantly is a 3rd server an optimal solution?
> Any help would be greatly appreciated.
>
|||In merge replication you will have Distributor, Publisher and Subscriber.
They are different roles for a replication setup but they can be on the same
physical machine. I think the 3rd server you mentioned is distributor. You
can setup the distributor on the same server with the publisher, so you
don't need a third machine.
Yi Chen
"Lucas Graf" <lgraf2000@.comcast.net> wrote in message
news:OjZ0E0bQGHA.5296@.TK2MSFTNGP09.phx.gbl...
> We have had a server in LocationA for quite some time. The need arose
> recently to have a server setup in LocationB due to some bandwidth issues.
> LocationB was given a snapshot of the DB @. LocationA when it was first
> setup. However, both machines will need to have the same data as both are
> used in a production environment. I will probably want to do this
> nightly.
> I have read a lot of posts and webistes, but still am semi in the dark.
> About the only thing i've figured out (i think) is that I will need to do
> some sort of merge replicaiton.
> What do I need to do to get started, a link to a HOW TO for a smiliar
> setup would be great. I have read a bit and some mention having a 3rd
> server, do i need a 3rd server as the final merged server? I guess more
> importantly is a 3rd server an optimal solution?
> Any help would be greatly appreciated.
>
|||Ok. That makes sense.
I have been messing around trying to set it up today, and am still lost.
Currently the 2 servers are out of sync. Both have data the other doesn't.
What do I need to do to get them both to have the same data now, and then
keep them replciating from here on out?
"Yi Chen [MSFT]" <yiche@.online.microsoft.com> wrote in message
news:%23o7jSucQGHA.1204@.TK2MSFTNGP12.phx.gbl...
> In merge replication you will have Distributor, Publisher and Subscriber.
> They are different roles for a replication setup but they can be on the
> same physical machine. I think the 3rd server you mentioned is
> distributor. You can setup the distributor on the same server with the
> publisher, so you don't need a third machine.
> Yi Chen
> "Lucas Graf" <lgraf2000@.comcast.net> wrote in message
> news:OjZ0E0bQGHA.5296@.TK2MSFTNGP09.phx.gbl...
>
|||Lucas Graf wrote:
> We have had a server in LocationA for quite some time. The need arose
> recently to have a server setup in LocationB due to some bandwidth issues.
> LocationB was given a snapshot of the DB @. LocationA when it was first
> setup. However, both machines will need to have the same data as both are
> used in a production environment. I will probably want to do this nightly.
> I have read a lot of posts and webistes, but still am semi in the dark.
> About the only thing i've figured out (i think) is that I will need to do
> some sort of merge replicaiton.
> What do I need to do to get started, a link to a HOW TO for a smiliar setup
> would be great. I have read a bit and some mention having a 3rd server, do
> i need a 3rd server as the final merged server? I guess more importantly is
> a 3rd server an optimal solution?
> Any help would be greatly appreciated.
|||Lucas,
presumably you have initialized the subscriber and are using merge
replication? If so, you just need to synchronize the subscriber to have the
data merged. You'll need to consider who should win conflicts (publisher by
default) and if conflicts should be allowed (filtering).
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Ok.
I got this far and was tentative on going further. I will keep trucking and
see what else may come up that causes issues. Thanks for the help so far, I
hope to report back a positive experience.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23ogHO4uQGHA.2628@.TK2MSFTNGP15.phx.gbl...
> Lucas,
> presumably you have initialized the subscriber and are using merge
> replication? If so, you just need to synchronize the subscriber to have
> the data merged. You'll need to consider who should win conflicts
> (publisher by default) and if conflicts should be allowed (filtering).
> Cheers,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||I guess I am still confused w/the whole publisher/distributor thing.
Since I want both servers to merge both of their data are they both set to
publishers and distributors? Or is only 1 a publisher and both distributors
and subscribers?
So confused..
"Lucas Graf" <lgraf2000@.comcast.net> wrote in message
news:Ob$pMuzQGHA.2436@.TK2MSFTNGP11.phx.gbl...
> Ok.
> I got this far and was tentative on going further. I will keep trucking
> and see what else may come up that causes issues. Thanks for the help so
> far, I hope to report back a positive experience.
>
> "Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
> news:%23ogHO4uQGHA.2628@.TK2MSFTNGP15.phx.gbl...
>
|||Ok.
ServerA
I have set him to a Distributor, Publisher and set the Database i want to
publish to the other server as the "push" datatabase. All seems good on
ServerA.
ServerB
Not sure what to do here so its data gets pushed to ServerA to be merged
there as well. Everything I try i end up getting the error "You cannot
create a merge replicaion in database xxxc. The database contains one or
more merge subscritptions that are anonymous or that use the Priority of the
Publisher when resolving conflicts."
"Lucas Graf" <lgraf@.nvidia.com> wrote in message
news:uSQuaI8QGHA.5552@.TK2MSFTNGP14.phx.gbl...
>I guess I am still confused w/the whole publisher/distributor thing.
> Since I want both servers to merge both of their data are they both set to
> publishers and distributors? Or is only 1 a publisher and both
> distributors and subscribers?
> So confused..
>
> "Lucas Graf" <lgraf2000@.comcast.net> wrote in message
> news:Ob$pMuzQGHA.2436@.TK2MSFTNGP11.phx.gbl...
>
|||Maybe Bidirectional Transactional Replication is more what I am looking for?
"Lucas Graf" <lgraf@.nvidia.com> wrote in message
news:uSQuaI8QGHA.5552@.TK2MSFTNGP14.phx.gbl...
>I guess I am still confused w/the whole publisher/distributor thing.
> Since I want both servers to merge both of their data are they both set to
> publishers and distributors? Or is only 1 a publisher and both
> distributors and subscribers?
> So confused..
>
> "Lucas Graf" <lgraf2000@.comcast.net> wrote in message
> news:Ob$pMuzQGHA.2436@.TK2MSFTNGP11.phx.gbl...
>
Complete Newbie Question
I have just installed Reporting Services and created a few reports that
I want to run in a web page - that seems easy enough to do but my boss
has asked me to provide a batch reporting solution.
He wants users to be able to request a report and the request be
written away to a sql db. I have a windows service that picks up all
new requests and fires up some .exe's depending on what sort of request
it is e.g password reset , password reminder etc..
When the reports are run I need them to be saved as PDF's into a
specific folder that can be accessed later from a web page.
Now all this is written and working using ActiveReports for .NET but we
hate that package and want to use sql reporting services. Can it be
done in sql reporting services and if so how do I do it - I mean I need
some real code examples
any help would be brilliant
cheers
JimI have been using log4net to log to SQL DB. You can log the web request when
reports are rendered. It is upto you to write the logic to who views the
page( for eg using session object who the user was like,
Session["UserName"]). log4net allows you to log when certain events are
triggered blah blah... Check out:
http://logging.apache.org/log4net/release/config-examples.html
Look for ADONETAppender which is what you want.
HTH
Rajesh Meenrajan
MCSD.NET
http://meenrajan.blogspot.com
"JimW13UK" wrote:
> I have just installed Reporting Services and created a few reports that
> I want to run in a web page - that seems easy enough to do but my boss
> has asked me to provide a batch reporting solution.
> He wants users to be able to request a report and the request be
> written away to a sql db. I have a windows service that picks up all
> new requests and fires up some .exe's depending on what sort of request
> it is e.g password reset , password reminder etc..
> When the reports are run I need them to be saved as PDF's into a
> specific folder that can be accessed later from a web page.
> Now all this is written and working using ActiveReports for .NET but we
> hate that package and want to use sql reporting services. Can it be
> done in sql reporting services and if so how do I do it - I mean I need
> some real code examples
> any help would be brilliant
> cheers
> Jim
>
I want to run in a web page - that seems easy enough to do but my boss
has asked me to provide a batch reporting solution.
He wants users to be able to request a report and the request be
written away to a sql db. I have a windows service that picks up all
new requests and fires up some .exe's depending on what sort of request
it is e.g password reset , password reminder etc..
When the reports are run I need them to be saved as PDF's into a
specific folder that can be accessed later from a web page.
Now all this is written and working using ActiveReports for .NET but we
hate that package and want to use sql reporting services. Can it be
done in sql reporting services and if so how do I do it - I mean I need
some real code examples
any help would be brilliant
cheers
JimI have been using log4net to log to SQL DB. You can log the web request when
reports are rendered. It is upto you to write the logic to who views the
page( for eg using session object who the user was like,
Session["UserName"]). log4net allows you to log when certain events are
triggered blah blah... Check out:
http://logging.apache.org/log4net/release/config-examples.html
Look for ADONETAppender which is what you want.
HTH
Rajesh Meenrajan
MCSD.NET
http://meenrajan.blogspot.com
"JimW13UK" wrote:
> I have just installed Reporting Services and created a few reports that
> I want to run in a web page - that seems easy enough to do but my boss
> has asked me to provide a batch reporting solution.
> He wants users to be able to request a report and the request be
> written away to a sql db. I have a windows service that picks up all
> new requests and fires up some .exe's depending on what sort of request
> it is e.g password reset , password reminder etc..
> When the reports are run I need them to be saved as PDF's into a
> specific folder that can be accessed later from a web page.
> Now all this is written and working using ActiveReports for .NET but we
> hate that package and want to use sql reporting services. Can it be
> done in sql reporting services and if so how do I do it - I mean I need
> some real code examples
> any help would be brilliant
> cheers
> Jim
>
COMPLETE NEWBIE - sorry :-(
I have mysql running on a windows2003 webserver - it runs a
messageboard and oscommerce. Potential new client wants to replicate
information from the website to her server - is this possible with
mysql or do I need to install sql (proper) ... sorry if I sound like I
don't know fully what I am doing - i dont!!
Any advice or pointers given would be greatly appreciated.
thanks
Jeff
Jeff/Andrew,
this is a MS SQL Server Replication newsgroup - surely there are dedicated
MySQL discussion boards?
Rgds,
Paul Ibison
|||On Sun, 24 Apr 2005 19:07:16 +0100, "Paul Ibison"
<Paul.Ibison@.Pygmalion.Com> wrote:
>Jeff/Andrew,
>this is a MS SQL Server Replication newsgroup - surely there are dedicated
>MySQL discussion boards?
>Rgds,
>Paul Ibison
>
I can't find one and I suspect I will end up installing SQL for
replication - can someone please advise?
|||Have a look at http://forums.mysql.com/list.php?26
From the point of view of SQL Server Replication, you can certainly achieve
your aim. For the new client you need to consider latency (time between
change on the publisher and corresponding change arriving at the subscriber)
, autonomy (can they be offline) and if the subscriber is read-only or
read-write. Answering these will lead to the correct type of replication.
Having SQL Server on the webserver would mean this is the publisher.
Heterogenous subscribers are supported to differing extents, but
connectivity to MYSQL is possible and is illustrated in Hilary's book below.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||while I'd love you to buy my book
1) its covered on the free downloadable sample chapter
http://www.nwsu.com/lowres_replication_ch02.pdf
2) Replication to MySQL doesn't work - or works until the distribution agent
stops and then you have to resync to get it working again due to a SQL
Server bug.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23CtbxJQSFHA.2748@.TK2MSFTNGP09.phx.gbl...
> Have a look at http://forums.mysql.com/list.php?26
> From the point of view of SQL Server Replication, you can certainly
> achieve your aim. For the new client you need to consider latency (time
> between change on the publisher and corresponding change arriving at the
> subscriber) , autonomy (can they be offline) and if the subscriber is
> read-only or read-write. Answering these will lead to the correct type of
> replication. Having SQL Server on the webserver would mean this is the
> publisher. Heterogenous subscribers are supported to differing extents,
> but connectivity to MYSQL is possible and is illustrated in Hilary's book
> below.
> HTH,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Interesting - thanks for the clarification. In that case your (Andrew's)
client might want to consider MSDE as a replacement for a MySQL subscriber.
Rgds,
Paul Ibison
messageboard and oscommerce. Potential new client wants to replicate
information from the website to her server - is this possible with
mysql or do I need to install sql (proper) ... sorry if I sound like I
don't know fully what I am doing - i dont!!
Any advice or pointers given would be greatly appreciated.
thanks
Jeff
Jeff/Andrew,
this is a MS SQL Server Replication newsgroup - surely there are dedicated
MySQL discussion boards?
Rgds,
Paul Ibison
|||On Sun, 24 Apr 2005 19:07:16 +0100, "Paul Ibison"
<Paul.Ibison@.Pygmalion.Com> wrote:
>Jeff/Andrew,
>this is a MS SQL Server Replication newsgroup - surely there are dedicated
>MySQL discussion boards?
>Rgds,
>Paul Ibison
>
I can't find one and I suspect I will end up installing SQL for
replication - can someone please advise?
|||Have a look at http://forums.mysql.com/list.php?26
From the point of view of SQL Server Replication, you can certainly achieve
your aim. For the new client you need to consider latency (time between
change on the publisher and corresponding change arriving at the subscriber)
, autonomy (can they be offline) and if the subscriber is read-only or
read-write. Answering these will lead to the correct type of replication.
Having SQL Server on the webserver would mean this is the publisher.
Heterogenous subscribers are supported to differing extents, but
connectivity to MYSQL is possible and is illustrated in Hilary's book below.
HTH,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||while I'd love you to buy my book
1) its covered on the free downloadable sample chapter
http://www.nwsu.com/lowres_replication_ch02.pdf
2) Replication to MySQL doesn't work - or works until the distribution agent
stops and then you have to resync to get it working again due to a SQL
Server bug.
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:%23CtbxJQSFHA.2748@.TK2MSFTNGP09.phx.gbl...
> Have a look at http://forums.mysql.com/list.php?26
> From the point of view of SQL Server Replication, you can certainly
> achieve your aim. For the new client you need to consider latency (time
> between change on the publisher and corresponding change arriving at the
> subscriber) , autonomy (can they be offline) and if the subscriber is
> read-only or read-write. Answering these will lead to the correct type of
> replication. Having SQL Server on the webserver would mean this is the
> publisher. Heterogenous subscribers are supported to differing extents,
> but connectivity to MYSQL is possible and is illustrated in Hilary's book
> below.
> HTH,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Interesting - thanks for the clarification. In that case your (Andrew's)
client might want to consider MSDE as a replacement for a MySQL subscriber.
Rgds,
Paul Ibison
Labels:
amessageboard,
client,
complete,
database,
microsoft,
mysql,
newbie,
oracle,
oscommerce,
potential,
replicateinformation,
running,
runs,
server,
sql,
webserver,
windows2003
complete newbie
would someone me so good as to help me out with the script for a basic
customer table ? , usualy fields, userid (primary key) name, address,
creditcard number, card type, phone number, email address?
customer table ? , usualy fields, userid (primary key) name, address,
creditcard number, card type, phone number, email address?
TIAHi
Look at
http://www.databaseanswers.org/data_models/index.htm
Regards
----------
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"strawberry" <1@.2.com> wrote in message
news:6iA9e.13718$DU6.5013@.newsfe1-gui.ntli.net...
> would someone me so good as to help me out with the script for a basic
> customer table ? , usualy fields, userid (primary key) name, address,
> creditcard number, card type, phone number, email address?
>
> TIA
compiler -- newbie q
Hi,
I am very new to xml. i have downloaded some sample data from MS and there
is file in there called: CustService.sln
I am required to comile this file. How do I compile it? I dont have a
comiler on my computer.
Thanks,
A .sln file is a Visual Studio .NET solution file. I suspect the example
assumes you have Visual Studio installed.
Cheers,
Graeme
--
Graeme Malcolm
Principal Technologist
Content Master Ltd.
www.contentmaster.com
www.microsoft.com/mspress/books/6137.asp
"Hasan Kachal" <kachal@.nospam.com> wrote in message
news:Os4q60LTEHA.2544@.TK2MSFTNGP10.phx.gbl...
Hi,
I am very new to xml. i have downloaded some sample data from MS and there
is file in there called: CustService.sln
I am required to comile this file. How do I compile it? I dont have a
comiler on my computer.
Thanks,
I am very new to xml. i have downloaded some sample data from MS and there
is file in there called: CustService.sln
I am required to comile this file. How do I compile it? I dont have a
comiler on my computer.
Thanks,
A .sln file is a Visual Studio .NET solution file. I suspect the example
assumes you have Visual Studio installed.
Cheers,
Graeme
--
Graeme Malcolm
Principal Technologist
Content Master Ltd.
www.contentmaster.com
www.microsoft.com/mspress/books/6137.asp
"Hasan Kachal" <kachal@.nospam.com> wrote in message
news:Os4q60LTEHA.2544@.TK2MSFTNGP10.phx.gbl...
Hi,
I am very new to xml. i have downloaded some sample data from MS and there
is file in there called: CustService.sln
I am required to comile this file. How do I compile it? I dont have a
comiler on my computer.
Thanks,
Subscribe to:
Posts (Atom)