Change user type from char to vchar

We have a requirement to change a user defined type from char(4) to vchar(4).
I was wondering whether there's a easier(quickest) method to do this as opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this type.
Thanks,
Manod
ALTER TABLE ...
ALTER COLUMN
The stored procedure, view, and function dependencies should not matter;
however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
and Defaults that may be created on this field.
If you use the database designer tool, EM will usually script out a new
table with all of the dependency drops and recreates, move all of the data,
and drop and rename the tables for you.
This is usually not the best way to do this, especially for very large
tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
good way to learn at least the details if not a poorer solution.
Sincerely,
Anthony Thomas

"sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:69e9c64b.0503090211.3552c797@.posting.google.c om...
We have a requirement to change a user defined type from char(4) to
vchar(4).
I was wondering whether there's a easier(quickest) method to do this as
opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this
type.
Thanks,
Manod
|||Thanks Anthony...I was hoping that there would be an easier option than going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas
|||Well, there is. As I stated before, if you use the Table Designer through
the EM, it will handle all of the scripting for you. It usually will just
do the creat, copy, drop, replace method, which can work, but it will take a
lot of resources to pull off on larger tables. The same could be done, just
do the same thing except save as script instead save. Keep the drop and
create dependencies, just replace the create, copy, and rename table pieces
with a single ALTER TABLE ... ALTER COLUMN statement. At leas this way, you
would have to parse the dependencies.
There is a caveat to this, however; the EM uses the sysdependencies to
script out all the drops and creates. If you have ever renamed an object
without dropping and recreating the dependencies, and have gotten that
little error message, this means the records in this system table have not
been updated to reflect the name change. So, the little wizard inside the
EM scripter will not catch everything...but your errors will.
Good luck.
Anthony Thomas

"Sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:15EEA5C6-8281-41FB-8287-085E1193F84F@.microsoft.com...
Thanks Anthony...I was hoping that there would be an easier option than
going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the
data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas

Change user type from char to vchar

We have a requirement to change a user defined type from char(4) to vchar(4)
.
I was wondering whether there's a easier(quickest) method to do this as oppo
sed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this ty
pe.
Thanks,
ManodALTER TABLE ...
ALTER COLUMN
The stored procedure, view, and function dependencies should not matter;
however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
and Defaults that may be created on this field.
If you use the database designer tool, EM will usually script out a new
table with all of the dependency drops and recreates, move all of the data,
and drop and rename the tables for you.
This is usually not the best way to do this, especially for very large
tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
good way to learn at least the details if not a poorer solution.
Sincerely,
Anthony Thomas
"sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:69e9c64b.0503090211.3552c797@.posting.google.com...
We have a requirement to change a user defined type from char(4) to
vchar(4).
I was wondering whether there's a easier(quickest) method to do this as
opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this
type.
Thanks,
Manod|||Thanks Anthony...I was hoping that there would be an easier option than goin
g
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the data
,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas|||Well, there is. As I stated before, if you use the Table Designer through
the EM, it will handle all of the scripting for you. It usually will just
do the creat, copy, drop, replace method, which can work, but it will take a
lot of resources to pull off on larger tables. The same could be done, just
do the same thing except save as script instead save. Keep the drop and
create dependencies, just replace the create, copy, and rename table pieces
with a single ALTER TABLE ... ALTER COLUMN statement. At leas this way, you
would have to parse the dependencies.
There is a caveat to this, however; the EM uses the sysdependencies to
script out all the drops and creates. If you have ever renamed an object
without dropping and recreating the dependencies, and have gotten that
little error message, this means the records in this system table have not
been updated to reflect the name change. So, the little wizard inside the
EM scripter will not catch everything...but your errors will.
Good luck.
Anthony Thomas
"Sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:15EEA5C6-8281-41FB-8287-085E1193F84F@.microsoft.com...
Thanks Anthony...I was hoping that there would be an easier option than
going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the
data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas

Change user type from char to vchar

We have a requirement to change a user defined type from char(4) to vchar(4)
.
I was wondering whether there's a easier(quickest) method to do this as oppo
sed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this ty
pe.
Thanks,
ManodALTER TABLE ...
ALTER COLUMN
The stored procedure, view, and function dependencies should not matter;
however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
and Defaults that may be created on this field.
If you use the database designer tool, EM will usually script out a new
table with all of the dependency drops and recreates, move all of the data,
and drop and rename the tables for you.
This is usually not the best way to do this, especially for very large
tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
good way to learn at least the details if not a poorer solution.
Sincerely,
Anthony Thomas
"sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:69e9c64b.0503090211.3552c797@.posting.google.com...
We have a requirement to change a user defined type from char(4) to
vchar(4).
I was wondering whether there's a easier(quickest) method to do this as
opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this
type.
Thanks,
Manod|||Thanks Anthony...I was hoping that there would be an easier option than goin
g
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the data
,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas|||Well, there is. As I stated before, if you use the Table Designer through
the EM, it will handle all of the scripting for you. It usually will just
do the creat, copy, drop, replace method, which can work, but it will take a
lot of resources to pull off on larger tables. The same could be done, just
do the same thing except save as script instead save. Keep the drop and
create dependencies, just replace the create, copy, and rename table pieces
with a single ALTER TABLE ... ALTER COLUMN statement. At leas this way, you
would have to parse the dependencies.
There is a caveat to this, however; the EM uses the sysdependencies to
script out all the drops and creates. If you have ever renamed an object
without dropping and recreating the dependencies, and have gotten that
little error message, this means the records in this system table have not
been updated to reflect the name change. So, the little wizard inside the
EM scripter will not catch everything...but your errors will.
Good luck.
Anthony Thomas
"Sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:15EEA5C6-8281-41FB-8287-085E1193F84F@.microsoft.com...
Thanks Anthony...I was hoping that there would be an easier option than
going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:

> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the
data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas

Change user type from char to vchar

We have a requirement to change a user defined type from char(4) to vchar(4).
I was wondering whether there's a easier(quickest) method to do this as opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this type.
Thanks,
ManodALTER TABLE ...
ALTER COLUMN
The stored procedure, view, and function dependencies should not matter;
however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
and Defaults that may be created on this field.
If you use the database designer tool, EM will usually script out a new
table with all of the dependency drops and recreates, move all of the data,
and drop and rename the tables for you.
This is usually not the best way to do this, especially for very large
tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
good way to learn at least the details if not a poorer solution.
Sincerely,
Anthony Thomas
"sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:69e9c64b.0503090211.3552c797@.posting.google.com...
We have a requirement to change a user defined type from char(4) to
vchar(4).
I was wondering whether there's a easier(quickest) method to do this as
opposed to:
- Drop dependent storedprocs and views
- rename type
- add type with new def
- reattach table columns
- drop old type
- recreate storedprocs,views
Yes, we have quite a few tables, storedproc and views that reference this
type.
Thanks,
Manod|||Thanks Anthony...I was hoping that there would be an easier option than going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:
> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas|||Well, there is. As I stated before, if you use the Table Designer through
the EM, it will handle all of the scripting for you. It usually will just
do the creat, copy, drop, replace method, which can work, but it will take a
lot of resources to pull off on larger tables. The same could be done, just
do the same thing except save as script instead save. Keep the drop and
create dependencies, just replace the create, copy, and rename table pieces
with a single ALTER TABLE ... ALTER COLUMN statement. At leas this way, you
would have to parse the dependencies.
There is a caveat to this, however; the EM uses the sysdependencies to
script out all the drops and creates. If you have ever renamed an object
without dropping and recreating the dependencies, and have gotten that
little error message, this means the records in this system table have not
been updated to reflect the name change. So, the little wizard inside the
EM scripter will not catch everything...but your errors will.
Good luck.
Anthony Thomas
"Sandiyan" <sandiyan@.yahoo.co.uk> wrote in message
news:15EEA5C6-8281-41FB-8287-085E1193F84F@.microsoft.com...
Thanks Anthony...I was hoping that there would be an easier option than
going
through and sorting out dependencies and etc...
I hope this will be addressed in sql2005 - my bet is not!
regards,
Sandiyan.
"Anthony Thomas" wrote:
> ALTER TABLE ...
> ALTER COLUMN
> The stored procedure, view, and function dependencies should not matter;
> however, you probably will have to drop and recreate any PKC, UC, FKC, CC,
> and Defaults that may be created on this field.
> If you use the database designer tool, EM will usually script out a new
> table with all of the dependency drops and recreates, move all of the
data,
> and drop and rename the tables for you.
> This is usually not the best way to do this, especially for very large
> tables, but you can "SAVE AS SCRIPT" instead of executing it. This is a
> good way to learn at least the details if not a poorer solution.
> Sincerely,
>
> Anthony Thomas

Change the font size in crystal report

Hi ,
I am using crytal report but my requirement is that .
I am using One formula field inside the formula field ,I have One string I want to change the font of a string .
How can I change the font of a string inside the formula editor.
Plz any one can Help me

Thanks Advanced............
Regards
NaltuPlace that formula field in the report
Goto format field and gto font and change that|||I am not putting the fomula field inside report .Again I am using it in the other formula field .|||Naltu,

I have a similar problem...have you found a solution to this??

thanks,

Change Notifications

Hello
I have a requirement to update the Exchange contacts folder according
to a table in MSSQL 200. Also changes in the db has to be updated in
the contacts.
The solution that I have thought about is to write a trigger and
contact a COM object that does the update. Is there a better way to do?
Thank you and regards
Renjith V.I helped someone with a similar requirement a while back. We ended up using
DAV and a Windows Service that checked the table to do the updates en masse
every 5 minutes or so. Depends on your requirements - if you need to have
immediate updates you could write an XP and avoid COM; or you could go the
COM route and use the 'sp_OA%' stored procs to invoke/manage it. I've never
invoked a COM routine from within a Trigger, however, so I couldn't tell you
about possible performance or other potential problems (although if you
don't properly destroy COM objects and/or you're not on SP 4, you can end up
with serious memory leaks.)
"Renjith" <v.renjith@.gmail.com> wrote in message
news:1150338308.044717.160160@.y41g2000cwy.googlegroups.com...
> Hello
> I have a requirement to update the Exchange contacts folder according
> to a table in MSSQL 200. Also changes in the db has to be updated in
> the contacts.
> The solution that I have thought about is to write a trigger and
> contact a COM object that does the update. Is there a better way to do?
> Thank you and regards
> Renjith V.
>|||Thank you Mike for the comments. But I am not sure what DAV and XP
mean. Could you please tell me a bit more about it?
Mike C# wrote:
> I helped someone with a similar requirement a while back. We ended up usi
ng
> DAV and a Windows Service that checked the table to do the updates en mass
e
> every 5 minutes or so. Depends on your requirements - if you need to have
> immediate updates you could write an XP and avoid COM; or you could go the
> COM route and use the 'sp_OA%' stored procs to invoke/manage it. I've nev
er
> invoked a COM routine from within a Trigger, however, so I couldn't tell y
ou
> about possible performance or other potential problems (although if you
> don't properly destroy COM objects and/or you're not on SP 4, you can end
up
> with serious memory leaks.)
> "Renjith" <v.renjith@.gmail.com> wrote in message
> news:1150338308.044717.160160@.y41g2000cwy.googlegroups.com...|||"Renjith" <v.renjith@.gmail.com> wrote in message
news:1150339498.386101.227740@.g10g2000cwb.googlegroups.com...
> Thank you Mike for the comments. But I am not sure what DAV and XP
> mean. Could you please tell me a bit more about it?
DAV is a web-based protocol you can use to retrieve and update information.
You can use it to update your Exchange folders. XP is an extended stored
procedure written in C++ and compiled to a DLL that SQL Server can invoke to
perform functions that are outside the normal scope of T-SQL.|||If you can update the contacts through Active Directory you can look linking
to the AD through VB/VBScript (DTS ActiveX Task), you could also link to SQL
Server through the same script, produce a recordset of the changes and apply
the changes to the AD.
If this is an option the best place to start would probably be:
http://www.microsoft.com/technet/sc...er/default.mspx
Ray
"Renjith" wrote:

> Hello
> I have a requirement to update the Exchange contacts folder according
> to a table in MSSQL 200. Also changes in the db has to be updated in
> the contacts.
> The solution that I have thought about is to write a trigger and
> contact a COM object that does the update. Is there a better way to do?
> Thank you and regards
> Renjith V.
>