Showing posts with label creating. Show all posts
Showing posts with label creating. Show all posts

Monday, March 26, 2012

How can I change the column width?

I'm creating a C# program in Visual Studio. When I query the sql database, the results are put into a data grid view. However, the column widths are always too small when displayed. I have text that is not shown because the column width is not large enough. I tried going into Sql Server Management Studio Express and trying to modify the size property of the columns, but it won't let me change it (its grayed out). How can I fix this problem?Why would you want changing size on the back end server when you need changing size of your grid cells.
You can provide functionality to popup a full text when grid cell double-clicked.

If you'll change backend column size to accommodate your grid size (which is unheard of) you will just truncate existing data in a database and have part of data instead of full set of data.

To limit number of characters returned from a backend to a front end you can use Substring function.

For more help describe your intentions in more detailed and it would be a wise posting it on .NET forum.

Good Luck.

Monday, March 19, 2012

How can control Transactions for creating Stored Procedure ?

I create StringBuilder type for

concating string to create a lot of stored procedure at once

However When I use this command

BEGIN TRANSACTION
BEGIN TRY
--////////////////////// SQL COMMAND /////////////////////////

------- This any command

--///////////////////////////////////////////////////////////
--COMMIT TRAN
END TRY

BEGIN CATCH
IF @.@.TRANCOUNT > 0
ROLLBACK TRANSACTION;
END CATCH

IF @.@.TRANCOUNT > 0
COMMIT TRANSACTION;

on any command

If I use

Create a lot of Tables

such as

BEGIN TRANSACTION
BEGIN TRY
--////////////////////// SQL COMMAND /////////////////////////

CREATE TABLE [dbo].[Table1](
Column1 Int ,
Column2 varchar(50) NULL
) ON [PRIMARY]

CREATE TABLE [dbo].[Table2](
Column1 Int ,
Column2 varchar(50) NULL
) ON [PRIMARY]

CREATE TABLE [dbo].[Table3](
Column1 Int ,
Column2 varchar(50) NULL
) ON [PRIMARY]

--///////////////////////////////////////////////////////////
--COMMIT TRAN
END TRY

BEGIN CATCH
IF @.@.TRANCOUNT > 0
ROLLBACK TRANSACTION;
END CATCH

IF @.@.TRANCOUNT > 0
COMMIT TRANSACTION;

It correctly works.

But if I need create a lot of Stored procedure

as the following code :


BEGIN TRANSACTION
BEGIN TRY
--////////////////////// SQL COMMAND /////////////////////////

CREATE PROCEDURE [dbo].[DeleteItem1]
@.ProcId Int,
@.RowVersion Int
AS
BEGIN
DELETE FROM [dbo].[ItemProcurement]
WHERE
[ProcId] = @.ProcId AND
[RowVersion] = @.RowVersion
END

CREATE PROCEDURE [dbo].[DeleteItem2]
@.ProcId Int
AS
BEGIN
DELETE FROM [dbo].[ItemProcurement]
WHERE
[ProcId] = @.ProcId
END


CREATE PROCEDURE [dbo].[DeleteItem3]
@.ProcId Int
AS
BEGIN
DELETE FROM [dbo].[ItemProcurement]
WHERE
[ProcId] = @.ProcId
END

--///////////////////////////////////////////////////////////
--COMMIT TRAN
END TRY

BEGIN CATCH
IF @.@.TRANCOUNT > 0
ROLLBACK TRANSACTION;
END CATCH

IF @.@.TRANCOUNT > 0
COMMIT TRANSACTION;


It occurs Error ???

Please help me

How should I solve them ?

the stored procedure create

CREATE PROCEDURE ..

have to be first in T-SQL command batch. You can do what you need by inserting each single procedure code into varchar(max) variable and run this code using EXEC command like

DECLARE @.lcCommand as varchar(max)

SET @.lcCommand ='CREATE PROCEDURE PROC1 .....'

EXEC (@.lcCommand)

SET @.lcCommand ='CREATE PROCEDURE PROC2 .....'

EXEC (@.lcCommand)

remember if you procedure definition is longer than 8000 chars split it into chunks not longer than 8000 chars to prevent errors( for some reason string passed to varchar(max) in single assign is cut at 8000 position if longer than 8000 chars)

Monday, February 27, 2012

Hot-Swappable dimensions

We are in the middle of creating a dataware house. In the current
model we have several hot-swappable (sub)dimensions which is linked to
a large dimension table. All dimensions are type 2. I don't think that
this is correct because when the data in the sub-dimension is changing
we need a new record in the large dimension too, otherwise you lose
the history of the record.
Instead I would like to create one FK in the Fact table which is
linked to all sub-dimensions. Because this key needs to be unique over
all sub-dimensions I am thinking about using a uniqueidentifier (16
byte GUID) field.
Is this the correct approach?
At a later stage at least 4 new hot-swappable dimensions will be
introduced.On May 2, 11:35 am, LuCarD <j...@.lucard.nl> wrote:
> We are in the middle of creating a dataware house. In the current
> model we have several hot-swappable (sub)dimensions which is linked to
> a large dimension table. All dimensions are type 2. I don't think that
> this is correct because when the data in the sub-dimension is changing
> we need a new record in the large dimension too, otherwise you lose
> the history of the record.
> Instead I would like to create one FK in the Fact table which is
> linked to all sub-dimensions. Because this key needs to be unique over
> all sub-dimensions I am thinking about using a uniqueidentifier (16
> byte GUID) field.
> Is this the correct approach?
> At a later stage at least 4 new hot-swappable dimensions will be
> introduced.
If you are going to create more than 2^31 record in the sub-dimension
table, probably you have to split that in several dimensions with a
reduced number of different values. Denormalizing the sub-dimension
into a "regular" dimension could be a good idea (it depends on many
other factors) but in this case there is no reason to continue using
surrogate keys with a tiny size (int or even smallint if you can).
When you have this data on the fact table, actually you preserved
history and you don't need to use SCD type 2 for these dimensions.
If you want to do more complex analysis, like "give me the sales of
this months projected on the organizational structure we had one year
ago", then you need to design a more complex model that will be much
difficult (and slow) to query, unless you use a particular OLAP model
like some of those described in the many-to-many paper you can find
here: http://www.sqlbi.eu/manytomany.aspx
Marco Russo
http://www.sqlbi.eu
http://sqlblog.com/blogs/marco_russo

Hot-Swappable dimensions

We are in the middle of creating a dataware house. In the current
model we have several hot-swappable (sub)dimensions which is linked to
a large dimension table. All dimensions are type 2. I don't think that
this is correct because when the data in the sub-dimension is changing
we need a new record in the large dimension too, otherwise you lose
the history of the record.
Instead I would like to create one FK in the Fact table which is
linked to all sub-dimensions. Because this key needs to be unique over
all sub-dimensions I am thinking about using a uniqueidentifier (16
byte GUID) field.
Is this the correct approach?
At a later stage at least 4 new hot-swappable dimensions will be
introduced.
On May 2, 11:35 am, LuCarD <j...@.lucard.nl> wrote:
> We are in the middle of creating a dataware house. In the current
> model we have several hot-swappable (sub)dimensions which is linked to
> a large dimension table. All dimensions are type 2. I don't think that
> this is correct because when the data in the sub-dimension is changing
> we need a new record in the large dimension too, otherwise you lose
> the history of the record.
> Instead I would like to create one FK in the Fact table which is
> linked to all sub-dimensions. Because this key needs to be unique over
> all sub-dimensions I am thinking about using a uniqueidentifier (16
> byte GUID) field.
> Is this the correct approach?
> At a later stage at least 4 new hot-swappable dimensions will be
> introduced.
If you are going to create more than 2^31 record in the sub-dimension
table, probably you have to split that in several dimensions with a
reduced number of different values. Denormalizing the sub-dimension
into a "regular" dimension could be a good idea (it depends on many
other factors) but in this case there is no reason to continue using
surrogate keys with a tiny size (int or even smallint if you can).
When you have this data on the fact table, actually you preserved
history and you don't need to use SCD type 2 for these dimensions.
If you want to do more complex analysis, like "give me the sales of
this months projected on the organizational structure we had one year
ago", then you need to design a more complex model that will be much
difficult (and slow) to query, unless you use a particular OLAP model
like some of those described in the many-to-many paper you can find
here: http://www.sqlbi.eu/manytomany.aspx
Marco Russo
http://www.sqlbi.eu
http://sqlblog.com/blogs/marco_russo