Showing posts with label limitation. Show all posts
Showing posts with label limitation. Show all posts

Wednesday, March 21, 2012

Question about IRowsetFastLoad::Commit(FALSE)

Hi,

If I use IRowsetFastLoad::Commit(FALSE) not IRowsetFastLoad::CommitCommit(TRUE), are there any limitation of IRowsetFastLoad::InsertRow(..) before Commit(FALSE)?

Now, I'm using everlastingly InsertRow(..) and Commit(FALSE) method repeatedly. A few days after, it seems not to work.

Implicit commit depends on the batch size. This can be set by SSPROP_FASTLOADOPTIONS. See e.g. IRowsetFastLoad Rowsets
What does not work for you?|||

The sqlserver.exe's memory usage increases up to 1G.

rgProps[0].dwOptions = DBPROPOPTIONS_REQUIRED;
rgProps[0].colid = DB_NULLID;
rgProps[0].vValue.vt = VT_BSTR;
rgProps[0].dwPropertyID = SSPROP_FASTLOADOPTIONS;//SSPROP_ENABLEFASTLOAD;
rgProps[0].vValue.bstrVal = L"ROWS_PER_BATCH = 10000,TABLOCK";

Saturday, February 25, 2012

Question

Can anyone tell me the limitation of the
xp_getfiledetails. I am executing this xp on a database
backup file and it's giving me a negative number?? The
real size is about 7 G......
Help pleasE!
Thanxs
wrote:
> Can anyone tell me the limitation of the
> xp_getfiledetails. I am executing this xp on a database
> backup file and it's giving me a negative number?? The
> real size is about 7 G......
> Help pleasE!
> Thanxs
xp_getfiledetails is an undocumented extended stored procedure and
therefore not supported by Microsoft. Looking at the output, it appears
the "Size" column is an INT, limited to just over a value of 2 billion.
When I run the procedure against a 3GB test file, I get: -1073741824.
Which appears to translate to the max INT size + the ABS() of the
returned value plus 1.
select cast(2147483647 as bigint) + cast(1073741824 as bigint) + 1
In any case, if the file were greater than 2x the largest integer size,
I'm not sure you could easily calculate the real value.
You may have to find an alternative.
David G.

Monday, February 20, 2012

Question

Can anyone tell me the limitation of the
xp_getfiledetails. I am executing this xp on a database
backup file and it's giving me a negative number'? The
real size is about 7 G......
Help pleasE!
Thanxs:) wrote:
> Can anyone tell me the limitation of the
> xp_getfiledetails. I am executing this xp on a database
> backup file and it's giving me a negative number'? The
> real size is about 7 G......
> Help pleasE!
> Thanxs
xp_getfiledetails is an undocumented extended stored procedure and
therefore not supported by Microsoft. Looking at the output, it appears
the "Size" column is an INT, limited to just over a value of 2 billion.
When I run the procedure against a 3GB test file, I get: -1073741824.
Which appears to translate to the max INT size + the ABS() of the
returned value plus 1.
select cast(2147483647 as bigint) + cast(1073741824 as bigint) + 1
In any case, if the file were greater than 2x the largest integer size,
I'm not sure you could easily calculate the real value.
You may have to find an alternative.
David G.

Question

Can anyone tell me the limitation of the
xp_getfiledetails. I am executing this xp on a database
backup file and it's giving me a negative number'? The
real size is about 7 G......
Help pleasE!
Thanxs wrote:
> Can anyone tell me the limitation of the
> xp_getfiledetails. I am executing this xp on a database
> backup file and it's giving me a negative number'? The
> real size is about 7 G......
> Help pleasE!
> Thanxs
xp_getfiledetails is an undocumented extended stored procedure and
therefore not supported by Microsoft. Looking at the output, it appears
the "Size" column is an INT, limited to just over a value of 2 billion.
When I run the procedure against a 3GB test file, I get: -1073741824.
Which appears to translate to the max INT size + the ABS() of the
returned value plus 1.
select cast(2147483647 as bigint) + cast(1073741824 as bigint) + 1
In any case, if the file were greater than 2x the largest integer size,
I'm not sure you could easily calculate the real value.
You may have to find an alternative.
David G.