Data storage

Does SQL SErver comprss the data it stores? or is a varchar(50) take up
that much space in the db?Jayme wrote:
> Does SQL SErver comprss the data it stores? or is a varchar(50) take up
> that much space in the db?
>
A field defined as CHAR(50) containing the value 'BLUE' will occupy 50
bytes, plus some overhead. A field defined as VARCHAR(50) containing
the value 'BLUE' will occupy 4 bytes, plus some overhead. Details are
in Books Online.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||On Thu, 27 Jul 2006 15:17:05 -0500, Tracy McKibben
<tracy@.realsqlguy.com> wrote:
>Jayme wrote:
>> Does SQL SErver comprss the data it stores? or is a varchar(50) take up
>> that much space in the db?
>A field defined as CHAR(50) containing the value 'BLUE' will occupy 50
>bytes, plus some overhead. A field defined as VARCHAR(50) containing
>the value 'BLUE' will occupy 4 bytes, plus some overhead. Details are
>in Books Online.
CHAR has overhead? I thought only VARCHAR had overhead.
Roy|||Roy Harvey wrote:
> On Thu, 27 Jul 2006 15:17:05 -0500, Tracy McKibben
> <tracy@.realsqlguy.com> wrote:
>> Jayme wrote:
>> Does SQL SErver comprss the data it stores? or is a varchar(50) take up
>> that much space in the db?
>> A field defined as CHAR(50) containing the value 'BLUE' will occupy 50
>> bytes, plus some overhead. A field defined as VARCHAR(50) containing
>> the value 'BLUE' will occupy 4 bytes, plus some overhead. Details are
>> in Books Online.
> CHAR has overhead? I thought only VARCHAR had overhead.
> Roy
Unless I'm mistaken, EVERY datatype has a small amount of overhead just
due to the column's existence. Isn't it one byte per column?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||> Unless I'm mistaken, EVERY datatype has a small amount of overhead just
> due to the column's existence. Isn't it one byte per column?
Perhaps you are thinking about the null bitmap that SQL Server includes for
both fixed and variable length columns. The total row overhead of the
bitmap field is CEILING(#cols * 8).
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:u%23jKUZesGHA.3556@.TK2MSFTNGP03.phx.gbl...
> Roy Harvey wrote:
>> On Thu, 27 Jul 2006 15:17:05 -0500, Tracy McKibben
>> <tracy@.realsqlguy.com> wrote:
>> Jayme wrote:
>> Does SQL SErver comprss the data it stores? or is a varchar(50) take up
>> that much space in the db?
>> A field defined as CHAR(50) containing the value 'BLUE' will occupy 50
>> bytes, plus some overhead. A field defined as VARCHAR(50) containing
>> the value 'BLUE' will occupy 4 bytes, plus some overhead. Details are
>> in Books Online.
>> CHAR has overhead? I thought only VARCHAR had overhead.
>> Roy
> Unless I'm mistaken, EVERY datatype has a small amount of overhead just
> due to the column's existence. Isn't it one byte per column?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||Dan Guzman wrote:
>> Unless I'm mistaken, EVERY datatype has a small amount of overhead just
>> due to the column's existence. Isn't it one byte per column?
> Perhaps you are thinking about the null bitmap that SQL Server includes for
> both fixed and variable length columns. The total row overhead of the
> bitmap field is CEILING(#cols * 8).
>
No, I'm just not wording my thoughts properly. What I'm trying to say
is, the mere fact that a CHAR column exists is causing some overhead in
the table. The column definition has to be stored somewhere. I guess
my original response should have stated that for all practical purposes,
VARCHAR has overhead that CHAR does not.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||On Fri, 28 Jul 2006 07:52:42 -0500, Tracy McKibben
<tracy@.realsqlguy.com> wrote:
>The column definition has to be stored somewhere.
syscolumns, or whatever serves that purpose these days.

Data storage

Does SQL SErver comprss the data it stores? or is a varchar(50) take up
that much space in the db?Jayme wrote:
> Does SQL SErver comprss the data it stores? or is a varchar(50) take up
> that much space in the db?
>
A field defined as CHAR(50) containing the value 'BLUE' will occupy 50
bytes, plus some overhead. A field defined as VARCHAR(50) containing
the value 'BLUE' will occupy 4 bytes, plus some overhead. Details are
in Books Online.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||On Thu, 27 Jul 2006 15:17:05 -0500, Tracy McKibben
<tracy@.realsqlguy.com> wrote:

>Jayme wrote:
>A field defined as CHAR(50) containing the value 'BLUE' will occupy 50
>bytes, plus some overhead. A field defined as VARCHAR(50) containing
>the value 'BLUE' will occupy 4 bytes, plus some overhead. Details are
>in Books Online.
CHAR has overhead? I thought only VARCHAR had overhead.
Roy|||Roy Harvey wrote:
> On Thu, 27 Jul 2006 15:17:05 -0500, Tracy McKibben
> <tracy@.realsqlguy.com> wrote:
>
> CHAR has overhead? I thought only VARCHAR had overhead.
> Roy
Unless I'm mistaken, EVERY datatype has a small amount of overhead just
due to the column's existence. Isn't it one byte per column?
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||> Unless I'm mistaken, EVERY datatype has a small amount of overhead just
> due to the column's existence. Isn't it one byte per column?
Perhaps you are thinking about the null bitmap that SQL Server includes for
both fixed and variable length columns. The total row overhead of the
bitmap field is CEILING(#cols * 8).
Hope this helps.
Dan Guzman
SQL Server MVP
"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:u%23jKUZesGHA.3556@.TK2MSFTNGP03.phx.gbl...
> Roy Harvey wrote:
> Unless I'm mistaken, EVERY datatype has a small amount of overhead just
> due to the column's existence. Isn't it one byte per column?
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com|||Dan Guzman wrote:
> Perhaps you are thinking about the null bitmap that SQL Server includes fo
r
> both fixed and variable length columns. The total row overhead of the
> bitmap field is CEILING(#cols * 8).
>
No, I'm just not wording my thoughts properly. What I'm trying to say
is, the mere fact that a CHAR column exists is causing some overhead in
the table. The column definition has to be stored somewhere. I guess
my original response should have stated that for all practical purposes,
VARCHAR has overhead that CHAR does not.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||On Fri, 28 Jul 2006 07:52:42 -0500, Tracy McKibben
<tracy@.realsqlguy.com> wrote:

>The column definition has to be stored somewhere.
syscolumns, or whatever serves that purpose these days.

Data Not Copying to MS Access Table

Hello,

I have a Data Flow Source that uses a SQL Command to pull data. In the SQL statement, I used CAST to change all varchar types to Nvarvchar to suit MS Access. I can preview the data from the source. In testing, the SQL statement only pulls about ten records.

I have a Microsoft 2000 Access database table as a destination. Data in each column in the table is required, and all columns have defaults.

I also have a grid data viewer set up. I have the DefaultBufferMaxRows set to 2 so that I can see data going across. When I execute this dataflow, no data is transfered to the Access database table. No data shows up in the dataviewer. There are no errors. The 'Execution Results' tab does not show errors, but indicates that zero rows were transfered. There are no warnings.

How do I begin to isolate the problem? The following is the SQL Statement in the Data Flow Source. Thank you for your help! - cdun2

DECLARE @.CategoryTable TABLE
(ColID Int,
ColCategory varchar(60),
ColValue varchar(500)
)

--and fill it

INSERT INTO @.CategoryTable
(ColID, ColCategory, ColValue)
SELECT
0,
LEFT(RawCollectionData,CHARINDEX(':',RawCollectionData)),
LTRIM(SUBSTRING(RawCollectionData,CHARINDEX(':',RawCollectionData)+1,255))
FROM Collections_Staging

--Assign an ID to each block of data for each occurance of 'Reason:'

DECLARE @.ID int
SET @.ID = 1
UPDATE @.CategoryTable
SET [ColID] = CASE WHEN ColCategory = 'Reason:' THEN @.ID - 1 ELSE @.ID END,
@.ID = CASE WHEN ColCategory = 'Reason:' THEN @.ID + 1 ELSE @.ID END

--Then put the data together

SELECT --cast to Nvarchar for MSAccess
a.ColID,
CAST(a.ColValue as Nvarchar(30)) AS OrderID,
COALESCE(CAST(b.ColValue as Nvarchar(30)),'') AS SellerUserID,
COALESCE(CAST(c.ColValue as Nvarchar(100)),'') AS BusinessName,
COALESCE(CAST(d.ColValue as Nvarchar(15)),'') AS BankID,
COALESCE(CAST(e.ColValue as Nvarchar(15)),'') AS AccountID,
COALESCE(CAST(SUBSTRING(f.ColValue,CHARINDEX('$',f.ColValue)+1,500)AS DECIMAL(18,2)),0) AS CollectionAmount,
COALESCE(CAST(g.ColValue as Nvarchar(10)),'') AS TransactionType,
CASE
WHEN h.ColValue LIKE '%Matching Disbursement%' THEN NULL
ELSE CAST(h.ColValue AS SmallDateTime)
END AS DisbursementDate,
--COALESCE(h.ColValue,'') AS DisbursementDate,
CASE
WHEN i.ColValue LIKE '%Matching Disbursements%' THEN NULL
WHEN CAST(LEFT(REVERSE(i.ColValue),4)AS INT) > 1000 THEN CAST(i.ColValue AS SmallDateTime)
WHEN LEFT(REVERSE(i.ColValue),4) = '1000' THEN NULL
END AS ReturnDate,
--COALESCE(i.ColValue,'') AS ReturnDate,
COALESCE(CAST(j.ColValue as Nvarchar(4)),'') AS Code,
COALESCE(CAST(k.ColValue as Nvarchar(255)),'') AS CollectionReason
FROM @.CategoryTable a
LEFT JOIN @.CategoryTable b ON b.ColID = a.ColID AND b.ColCategory = 'Seller UserId:'
LEFT JOIN @.CategoryTable c ON c.ColID = a.ColID AND c.ColCategory = 'Business Name:'
LEFT JOIN @.CategoryTable d ON d.ColID = a.ColID AND d.ColCategory = 'Bank ID:'
LEFT JOIN @.CategoryTable e ON e.ColID = a.ColID AND e.ColCategory = 'Account ID:'
LEFT JOIN @.CategoryTable f ON f.ColID = a.ColID AND f.ColCategory = 'Amount:'
LEFT JOIN @.CategoryTable g ON g.ColID = a.ColID AND g.ColCategory = 'Transaction Type:'
LEFT JOIN @.CategoryTable h ON h.ColID = a.ColID AND h.ColCategory = 'Disbursement Date:'
LEFT JOIN @.CategoryTable i ON i.ColID = a.ColID AND i.ColCategory = 'Return Date:'
LEFT JOIN @.CategoryTable j ON j.ColID = a.ColID AND j.ColCategory = 'Code:'
LEFT JOIN @.CategoryTable k ON k.ColID = a.ColID AND k.ColCategory = 'Reason:'

WHERE a.ColCategory = 'Order ID:'

Are you doing this on an x64 machine. Is it possible that your package is executed in 64-bit mode? There is no 64-bit version of the JET provider.

There have been many posts about this before. Seaarch this forum to get instructions for making sure the packages are executed in 32-bit mode.

Thanks,

Bob

|||

Hi Cdun,

When you preview the Source, do you find any rows existing for the query? If yes, When you execute the dataflow task can you see any rows in Data grid viewer?

In fact if there are rows, it must be transfered to the destination table.

Thanks

Subhash Subramanyam

|||

Subhash Subramanyam wrote:

When you execute the dataflow task can you see any rows in Data grid viewer?

There are rows in the preview, but no rows in the data grid viewer. I'll check into the 64 bit setting.

|||

Bob Bojanic - MSFT wrote:

Seaarch this forum to get instructions for making sure the packages are executed in 32-bit mode.

Thanks,

Bob

I went to the package properties, debugging, and set Run64BitRuntime to False. I still get the same result The data will preview, but will not transfer into the Access table.

In the Data Flow Task, I'm using an OLEDB source to execute the sql statement. Should I be using an Execute SQL Task instead? The sql statement also uses a TABLE variable. Could this be a problem?

|||There must be something wrong with the way I'm trying to deliver the data to the Access table, because I can't get data to a sql server table destination either.|||

Never mind on this. I resorted to creating a table UDF as the source, and it looks like that will work.

cdun2

Data Model: TypeCode Reference Tables

Hello World,
I have two two typcode reference tables with the following DDL:
CREATE TABLE [dbo].[LanguageType](
[Description] [varchar](255) NULL,
[LanguageTypeCode][char](6)NOT NULL
)
GO
ALTER TABLE dbo.LanguageType ADD CONSTRAINT
PK_LanguageType PRIMARY KEY CLUSTERED
(
LanguageTypeCode
)
GO
CREATE TABLE [dbo].[BookType](
[Description] [varchar](255) NULL,
[BookTypeCode] [char](6)NOT NULL
)
GO
ALTER TABLE dbo.BookType ADD CONSTRAINT
PK_BookType PRIMARY KEY CLUSTERED
(
BookTypeCode
)
GO
I need to create a template that has a referential constraints check against
the primary key of EITHER table above. For example,
ALTER TABLE dbo.Template ADD CONSTRAINT
PK_Template PRIMARY KEY CLUSTERED
(
TemplateID,
TypeCode -- Either LanguageTypeCode or BookTypeCode
)
What are the options that I have to implement this? I thought about
combining the Language and Book TypeCodes into one table, but we think that
would only complicate our data model. Please comment.Add a "parent" Table that has both TypeCoeds in it
Create Table TemplateTypeCode -- You can think of better name for this
abstraction
(TypeCode Char(6( Primary Key Not Null)
And alter both pf your other tables
Alter Table dbo.LanguageType
ADD CONSTRAINT FKTypeCode Foreign Key (LanguageTypeCode)
references TemplateTypeCode(TypeCode)
Alter Table dbo.BookType
ADD CONSTRAINT FKTypeCode Foreign Key (BookTypeCode)
references TemplateTypeCode(TypeCode)
Then create constraint on Template table agaist TemplateTypeCode Table
ALTER TABLE dbo.Template ADD CONSTRAINT
FK_TypeCodes (TypeCode)
references TemplateTypeCode(TypeCode)
"C TO" wrote:

> Hello World,
> I have two two typcode reference tables with the following DDL:
> CREATE TABLE [dbo].[LanguageType](
> [Description] [varchar](255) NULL,
> [LanguageTypeCode][char](6)NOT NULL
> )
> GO
> ALTER TABLE dbo.LanguageType ADD CONSTRAINT
> PK_LanguageType PRIMARY KEY CLUSTERED
> (
> LanguageTypeCode
> )
> GO
> CREATE TABLE [dbo].[BookType](
> [Description] [varchar](255) NULL,
> [BookTypeCode] [char](6)NOT NULL
> )
> GO
> ALTER TABLE dbo.BookType ADD CONSTRAINT
> PK_BookType PRIMARY KEY CLUSTERED
> (
> BookTypeCode
> )
> GO
> I need to create a template that has a referential constraints check again
st
> the primary key of EITHER table above. For example,
> ALTER TABLE dbo.Template ADD CONSTRAINT
> PK_Template PRIMARY KEY CLUSTERED
> (
> TemplateID,
> TypeCode -- Either LanguageTypeCode or BookTypeCode
> )
>
> What are the options that I have to implement this? I thought about
> combining the Language and Book TypeCodes into one table, but we think tha
t
> would only complicate our data model. Please comment.|||Thanks. Wouldn't this create more repeated data? How would you compare
creating a parent table with creating trigger to enforce referential
integrity?
"CBretana" wrote:
> Add a "parent" Table that has both TypeCoeds in it
> Create Table TemplateTypeCode -- You can think of better name for this
> abstraction
> (TypeCode Char(6( Primary Key Not Null)
> And alter both pf your other tables
> Alter Table dbo.LanguageType
> ADD CONSTRAINT FKTypeCode Foreign Key (LanguageTypeCode)
> references TemplateTypeCode(TypeCode)
> Alter Table dbo.BookType
> ADD CONSTRAINT FKTypeCode Foreign Key (BookTypeCode)
> references TemplateTypeCode(TypeCode)
> Then create constraint on Template table agaist TemplateTypeCode Table
> ALTER TABLE dbo.Template ADD CONSTRAINT
> FK_TypeCodes (TypeCode)
> references TemplateTypeCode(TypeCode)
>
> "C TO" wrote:
>|||A thing is either a type or a code, but not both. You also might want
to consider not blindly assigning columns a VARCHAR(255).
CREATE TABLE Languages
(language_code CHAR(3) NOT NULL PRIMARY KEY, -- ISO Standared 3166
language_name CHAR(15) NOT NULL);
CREATE TABLE BookTypes
( book_type CHAR(6) NOT NULL PRIMARY KEY, -- ABA codes? shop
categories?
book_description VARCHAR(25) NOT NULL);
against the primary key of EITHER table above. For example, ...
TypeCode -- Either LanguageTypeCode or BookTypeCode <<
No, you need a real relational design with well-defined attributes. It
is a total violation of just about every rule to have a column that
holds different attributes. That is less than First Normal Form.
table, but we think that would only complicate our data model. Please
comment. <<
That design flaw is called the "One True Lookup Table" and you can
Goolge for the painful details.
Here are some standards that might help:
1) If you need to know the language of a book, you can get it from the
fist two digits of the ISBN.
2) ISO 3166 standard reference with 2 letter, 3 letter and number
codes:
The standard ISO 639 provides two sets of language codes, one as a
two-letter code set (ISO 639-1:2002 Codes for the representation of
names of languages -- Part 1: Alpha-2 code) and another as a
three-letter code set (ISO 639-2:1998 Codes for the representation of
names of languages -- Part 2: Alpha-3 code). The ISO 639 code lists are
also made available via the Web site of the ISO 639 Joint Advisory
Committee.|||CTO,
Creating a parent table is the way I'd go... You ARE creating repeated
data (copies) of the Keys, but that happens anytime you have a Foreign Key
to Primary Key Constraint. This technique is called "subclassing". It's
advantedge is that the FK On the Template table can use built in DRI
COnstraint which is better performance and cleaner than using Trigger...
"C TO" wrote:
> Thanks. Wouldn't this create more repeated data? How would you compare
> creating a parent table with creating trigger to enforce referential
> integrity?
>
> "CBretana" wrote:
>|||Hi CELKO,
Your input is really helpful and make me think harder. First of all, the
examples I provided related to Book and Language types were bad in this case
because language is an attribute of the book. But I really meant to provide
examples that would answer my question about "One True Lookup Table" and the
referential integrity enforment.
Secondly, I have heard you mentioned ISO before and felt very helpless
soemtimes because I did not how to get access to the codes. I've tried, many
of them required "placing an order in the shopping cart". BTW, in general,
how do I know which are accessible to the Public?
There were really book or language in this model, but I am interested in
using the universal, standard reference codes. Thanks.
"--CELKO--" wrote:

> A thing is either a type or a code, but not both. You also might want
> to consider not blindly assigning columns a VARCHAR(255).
> CREATE TABLE Languages
> (language_code CHAR(3) NOT NULL PRIMARY KEY, -- ISO Standared 3166
> language_name CHAR(15) NOT NULL);
> CREATE TABLE BookTypes
> ( book_type CHAR(6) NOT NULL PRIMARY KEY, -- ABA codes? shop
> categories?
> book_description VARCHAR(25) NOT NULL);
>
> against the primary key of EITHER table above. For example, ...
> TypeCode -- Either LanguageTypeCode or BookTypeCode <<
> No, you need a real relational design with well-defined attributes. It
> is a total violation of just about every rule to have a column that
> holds different attributes. That is less than First Normal Form.
>
> table, but we think that would only complicate our data model. Please
> comment. <<
> That design flaw is called the "One True Lookup Table" and you can
> Goolge for the painful details.
> Here are some standards that might help:
> 1) If you need to know the language of a book, you can get it from the
> fist two digits of the ISBN.
> 2) ISO 3166 standard reference with 2 letter, 3 letter and number
> codes:
> The standard ISO 639 provides two sets of language codes, one as a
> two-letter code set (ISO 639-1:2002 Codes for the representation of
> names of languages -- Part 1: Alpha-2 code) and another as a
> three-letter code set (ISO 639-2:1998 Codes for the representation of
> names of languages -- Part 2: Alpha-3 code). The ISO 639 code lists are
> also made available via the Web site of the ISO 639 Joint Advisory
> Committee.
>|||Thanks. If that is the only common practice, then I would go that route too.
Talking about DRI, is that still available in SQL 2005?
"CBretana" wrote:
> CTO,
> Creating a parent table is the way I'd go... You ARE creating repeated
> data (copies) of the Keys, but that happens anytime you have a Foreign Ke
y
> to Primary Key Constraint. This technique is called "subclassing". It's
> advantedge is that the FK On the Template table can use built in DRI
> COnstraint which is better performance and cleaner than using Trigger...
> "C TO" wrote:
>|||Correction: I meant "there was not any book or language..."
"C TO" wrote:
> Hi CELKO,
> Your input is really helpful and make me think harder. First of all, the
> examples I provided related to Book and Language types were bad in this ca
se
> because language is an attribute of the book. But I really meant to provid
e
> examples that would answer my question about "One True Lookup Table" and t
he
> referential integrity enforment.
> Secondly, I have heard you mentioned ISO before and felt very helpless
> soemtimes because I did not how to get access to the codes. I've tried, ma
ny
> of them required "placing an order in the shopping cart". BTW, in general,
> how do I know which are accessible to the Public?
> There were really book or language in this model, but I am interested in
> using the universal, standard reference codes. Thanks.
>
>
> "--CELKO--" wrote:
>|||Hi CELKO,
I overlooked a point you pointed out about "A thing is either a type or a
code". Do you mean in general a type is usually a popular thing which can be
understood easily in a spoken/written language (e.g. Type of Language:
English, Spanish...) and the code is usually used for application only (e.g
.
EN, SP) ? So you were questioning why the column was named that way?
You further said, "You also might want to consider not blindly assigning
columns a VARCHAR(255)." What do you mean by that?
Say, I have a type of a thing that is not so common or not to have easily
standardized type, having a description column would allow further
explaination about that type. Why not?
"--CELKO--" wrote:

> A thing is either a type or a code, but not both. You also might want
> to consider not blindly assigning columns a VARCHAR(255).
> CREATE TABLE Languages
> (language_code CHAR(3) NOT NULL PRIMARY KEY, -- ISO Standared 3166
> language_name CHAR(15) NOT NULL);
> CREATE TABLE BookTypes
> ( book_type CHAR(6) NOT NULL PRIMARY KEY, -- ABA codes? shop
> categories?
> book_description VARCHAR(25) NOT NULL);
>
> against the primary key of EITHER table above. For example, ...
> TypeCode -- Either LanguageTypeCode or BookTypeCode <<
> No, you need a real relational design with well-defined attributes. It
> is a total violation of just about every rule to have a column that
> holds different attributes. That is less than First Normal Form.
>
> table, but we think that would only complicate our data model. Please
> comment. <<
> That design flaw is called the "One True Lookup Table" and you can
> Goolge for the painful details.
> Here are some standards that might help:
> 1) If you need to know the language of a book, you can get it from the
> fist two digits of the ISBN.
> 2) ISO 3166 standard reference with 2 letter, 3 letter and number
> codes:
> The standard ISO 639 provides two sets of language codes, one as a
> two-letter code set (ISO 639-1:2002 Codes for the representation of
> names of languages -- Part 1: Alpha-2 code) and another as a
> three-letter code set (ISO 639-2:1998 Codes for the representation of
> names of languages -- Part 2: Alpha-3 code). The ISO 639 code lists are
> also made available via the Web site of the ISO 639 Joint Advisory
> Committee.
>|||>> I did not how to get access to the codes. I've tried, many of them
required "placing an order in the shopping cart". BTW, in general, how
do I know which are accessible to the Public? <<
ISO makes its money from sales, while ANSI makes its money from
membership fees. ISOP is therefore not as open about things as ANSI.
You have to Google around like crazy sometimes to find out about a
Standard if you do not know the ISO number or a good search phrase for
the title. I think that thre might be market for a pocket guidebook to
various standard codes -- the name, source, purpose and brief
history/description of each one.

Data Getting truncated as I insert i.e. instead of inserting Hello it inserts H

m inserting some data in big-sized fieldand small-sized fields, data of varchar type, int's, dateTime, andothers... i am using something called a stored procedure to add datainto a table.. now when i execute the stored procedure my data getstruncated (although i made the sizes for my fields ridiculously biglike 1000 just in case) for example if i want to enter Jasmine it onlyinserts 'J' in the field
I am sure there's something wrong in the stored procedure, and I amguessing it's a problem of using single vs. double quotes and stufflike that within my insert statement...
the following is my stored procedure:
CREATE procedure addLabor
@.lName varchar,
@.fName varchar,
@.mName varchar,
@.title varchar,
@.craft varchar,
@.lastFour varchar,
@.SSN varchar,
@.dateOfHire varchar,
@.currentProj varchar,
@.status tinyInt,
@.project_id int,
@.updateBy varchar,
@.updateDate varchar,
@.address varchar,
@.email varchar,
@.phone varchar,
@.zip varchar,
@.myfeedBack varchar,
@.ethnicity varchar,
@.userID int
as
BEGIN
SET NOCOUNT OFF
DECLARE @.newid INT
insert into laborPersonal ( lName, fName, mName, title, craft,lastFour, SSN, dateOfHire, currentProj, status, project_id,updateBy,
updateDate, address, email, phone, zip, ethnicity)
VALUES
(@.lName , @.fName , @.mName , @.title , @.craft , @.lastFour , @.SSN ,@.dateOfHire , @.currentProj ,
@.status, @.project_id , @.UpdateBy, @.UpdateDate , @.address , @.email , @.phone , @.zip , @.ethnicity )
SELECT @.newid = SCOPE_IDENTITY()
insert into feedBack
(lID, feedBack, userID, project_id)
values
(@.newid ,+'
+@.myfeedBack + ',
+@.userID ,
@.project_id )
SET NOCOUNT ON
END
GO

When i use 2 single quotes it insert the following string: "@.lName" not the actual value of the variable @.lName
my exec statement is this:
EXEC addLabor 'Razor', 'Nazor', 'mid', 'Mr', 'Carpenter Forman','1234','keOWVozC+wmBvaqgkVkZci5y4vFLdTKfZOVG4C6BSN6H2MBP6pdsIWA0SdPAlPJra0EjEj+uXI/kXSiBuwwnKQ==','6/27/2005 12:00:00 AM' , 'O.C. Public Library', 1, 3, '3', '7/25/20052:38:02 PM', '1233 Shady Canyon, Irvine', '', '', '12345','123-12-1234', 'African American', '3'
I appreciate any help or hints
thanks to all
All of your parameters are declared like this:
@.lName varchar,
Should be like this:

@.lName varchar(1000),
a type of varchar is like varchar(1), meaning a variable length string with a max of 1 character. The number used should likely match the underlying length of the field in the table