Print button generates hugh spooled print files

Hi!
We are currently using a different third party tool to print out pdf-files
generated from SQL Server 2000 Reporting Services. We are a fairly large
international cooperation and have a centralized citrix it environment with
different band width to different places in the world. This makes the print
file size critical.
Because there havenâ't been any really good ways to print out reports before
sp2 we have hoped a lot of the sp2 print functionality. Now itâ's installed in
our test enviromnet and we are pretty disappointed.
It seems like the reports are converted to tiff-format and then printed and
the print file size is huge. We tested to print out a report with six pages
(A4-format) with different techniques and this is the result when it comes to
spooled print file sizes:
1. Using RS print button (14.1 MB)
2. Exporting to TIFF-format from RS and than print (14 MB)
3. Exporting to PDF-format and print with gsprint (ghostscript) using a
windows generic print driver (1.43 MB)
4. Exporting to PDF-format and print with gsprint (ghostscript) using a
print driver specialized for the current printer, hp laserjet (852 KB)
5. Exporting to PDF-format and print with acrobat reader (531 KB)
I have a couple of questions regarding this:
1. Is this right? Is the report converted to TIFF-format when pressing the
print button and is it right that the spooled print file should be this large
and in that case why is it done in this way?
2. Is there any work around for this? Is there any way to get a smaller file?
3. Is this the way it will be implemented in SQL Server 2005 as well?
Regards,
/MattiasHi Mattias,
I also noticed the problem and posted a while back but not got a reply yet
(we too also use Citrix and need to address the bandwidth issue!).
--
Ben
"MattiasT" wrote:
> Hi!
> We are currently using a different third party tool to print out pdf-files
> generated from SQL Server 2000 Reporting Services. We are a fairly large
> international cooperation and have a centralized citrix it environment with
> different band width to different places in the world. This makes the print
> file size critical.
> Because there havenâ't been any really good ways to print out reports before
> sp2 we have hoped a lot of the sp2 print functionality. Now itâ's installed in
> our test enviromnet and we are pretty disappointed.
> It seems like the reports are converted to tiff-format and then printed and
> the print file size is huge. We tested to print out a report with six pages
> (A4-format) with different techniques and this is the result when it comes to
> spooled print file sizes:
> 1. Using RS print button (14.1 MB)
> 2. Exporting to TIFF-format from RS and than print (14 MB)
> 3. Exporting to PDF-format and print with gsprint (ghostscript) using a
> windows generic print driver (1.43 MB)
> 4. Exporting to PDF-format and print with gsprint (ghostscript) using a
> print driver specialized for the current printer, hp laserjet (852 KB)
> 5. Exporting to PDF-format and print with acrobat reader (531 KB)
> I have a couple of questions regarding this:
> 1. Is this right? Is the report converted to TIFF-format when pressing the
> print button and is it right that the spooled print file should be this large
> and in that case why is it done in this way?
> 2. Is there any work around for this? Is there any way to get a smaller file?
> 3. Is this the way it will be implemented in SQL Server 2005 as well?
> Regards,
> /Mattias

Print button generates hugh print files

I have posted this before with no luck so I try again and hope for an answer.
Hi!
We are currently using a different third party tool to print out pdf-files
generated from SQL Server 2000 Reporting Services. We are a fairly large
international cooperation and have a centralized citrix it environment with
different band width to different places in the world. This makes the print
file size critical.
Because there havenâ't been any really good ways to print out reports before
sp2 we have hoped a lot of the sp2 print functionality. Now itâ's installed in
our test enviromnet and we are pretty disappointed.
It seems like the reports are converted to tiff-format and then printed and
the print file size is huge. We tested to print out a report with six pages
(A4-format) with different techniques and this is the result when it comes to
spooled print file sizes:
1. Using RS print button (14.1 MB)
2. Exporting to TIFF-format from RS and than print (14 MB)
3. Exporting to PDF-format and print with gsprint (ghostscript) using a
windows generic print driver (1.43 MB)
4. Exporting to PDF-format and print with gsprint (ghostscript) using a
print driver specialized for the current printer, hp laserjet (852 KB)
5. Exporting to PDF-format and print with acrobat reader (531 KB)
I have a couple of questions regarding this:
1. Is this right? Is the report converted to TIFF-format when pressing the
print button and is it right that the spooled print file should be this large
and in that case why is it done in this way?
2. Is there any work around for this? Is there any way to get a smaller file?
3. Is this the way it will be implemented in SQL Server 2005 as well?
Regards,
/MattiasReports are definitely not output to TIFF format. They are rendered to GDI
(which is a vector format) to send to the printer. I'm not sure what is
behind the size explosion. I will investigate on our side.
--
Brian Welcker
Group Program Manager
Microsoft SQL Server
This posting is provided "AS IS" with no warranties, and confers no rights.
"MattiasT" <MattiasT@.discussions.microsoft.com> wrote in message
news:DA2CF65D-D76A-4867-AFED-5A22AB356967@.microsoft.com...
>I have posted this before with no luck so I try again and hope for an
>answer.
> Hi!
> We are currently using a different third party tool to print out pdf-files
> generated from SQL Server 2000 Reporting Services. We are a fairly large
> international cooperation and have a centralized citrix it environment
> with
> different band width to different places in the world. This makes the
> print
> file size critical.
> Because there haven't been any really good ways to print out reports
> before
> sp2 we have hoped a lot of the sp2 print functionality. Now it's installed
> in
> our test enviromnet and we are pretty disappointed.
> It seems like the reports are converted to tiff-format and then printed
> and
> the print file size is huge. We tested to print out a report with six
> pages
> (A4-format) with different techniques and this is the result when it comes
> to
> spooled print file sizes:
> 1. Using RS print button (14.1 MB)
> 2. Exporting to TIFF-format from RS and than print (14 MB)
> 3. Exporting to PDF-format and print with gsprint (ghostscript) using a
> windows generic print driver (1.43 MB)
> 4. Exporting to PDF-format and print with gsprint (ghostscript) using a
> print driver specialized for the current printer, hp laserjet (852 KB)
> 5. Exporting to PDF-format and print with acrobat reader (531 KB)
> I have a couple of questions regarding this:
> 1. Is this right? Is the report converted to TIFF-format when pressing the
> print button and is it right that the spooled print file should be this
> large
> and in that case why is it done in this way?
> 2. Is there any work around for this? Is there any way to get a smaller
> file?
> 3. Is this the way it will be implemented in SQL Server 2005 as well?
> Regards,
> /Mattias
>

Primary, Indexes and Foreign Key - Best Place for them

Hello
I have a database with two data files PRIMARY and INDEXES.
To beef up performance I would like to move as much as I
can out of PRIMARY into Index so I would like to know the
best place to keep my Primary, Foreign and Indexes.
For instance, is it better to keep my Primary Keys in the
PRIMARY filegroup or move it to the INDEXES filegroup ?
Thanks
JWhat makes you think that you would get much if any benefit out of doing
this?
Keeping data in different filegroups doesn't necessarily do anything for
performance unless those filegroups are on differnet spindles. (ie physical
disks). Even then... most databases rarely have a need for different
filegroups. Instead, it's normally just as good for performance to simply
create multiple files within a single filegroup. Generally, I don't use
seperate filegroups unless I want a different backup strategy for difference
data sets.
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Julie" <anonymous@.discussions.microsoft.com> wrote in message
news:0a0e01c3a206$20fe0e10$a501280a@.phx.gbl...
> Hello
> I have a database with two data files PRIMARY and INDEXES.
> To beef up performance I would like to move as much as I
> can out of PRIMARY into Index so I would like to know the
> best place to keep my Primary, Foreign and Indexes.
> For instance, is it better to keep my Primary Keys in the
> PRIMARY filegroup or move it to the INDEXES filegroup ?
> Thanks
> J|||Thankyou for your post.
As I understand it, it is due to the read write heads of
SQL server only one head is allowed at one time per data
file.
Having more than one increases performance, though having
too many slows it.
According to the MCP course it is recommended that you
take your indexes out, and put them in a separate data
file, as then you will be able to ge immediatly from one
file to another.
Thanks
J
>--Original Message--
>What makes you think that you would get much if any
benefit out of doing
>this?
>Keeping data in different filegroups doesn't necessarily
do anything for
>performance unless those filegroups are on differnet
spindles. (ie physical
>disks). Even then... most databases rarely have a need
for different
>filegroups. Instead, it's normally just as good for
performance to simply
>create multiple files within a single filegroup.
Generally, I don't use
>seperate filegroups unless I want a different backup
strategy for difference
>data sets.
>--
>Brian Moran
>Principal Mentor
>Solid Quality Learning
>SQL Server MVP
>http://www.solidqualitylearning.com
>
>"Julie" <anonymous@.discussions.microsoft.com> wrote in
message
>news:0a0e01c3a206$20fe0e10$a501280a@.phx.gbl...
>> Hello
>> I have a database with two data files PRIMARY and
INDEXES.
>> To beef up performance I would like to move as much as I
>> can out of PRIMARY into Index so I would like to know
the
>> best place to keep my Primary, Foreign and Indexes.
>> For instance, is it better to keep my Primary Keys in
the
>> PRIMARY filegroup or move it to the INDEXES filegroup ?
>> Thanks
>> J
>
>.
>|||Julie
Seems to be some confusion here. You say data files, but
it sounds like you are talking about file groups. I agree
with Brian, in that do not create multiple file groups
unless you know you need them.
If you are using multiple physical disks, SQL Server
usually does a good job of striping the tables across the
disks. If you do have one of more large tables that are
very active it can be a benefit to put the non-clustered
indexes in a seperate filegroup. Providing that filegroup
is on different physical drives. I would advise against
doing it as a matter of course, only do it if you can
prove it is an issue.
Hope this helps
John|||Thankyou both for your responses, it looks as if I have my
wires crossed somewhere.
J
>--Original Message--
>Julie
>Seems to be some confusion here. You say data files, but
>it sounds like you are talking about file groups. I agree
>with Brian, in that do not create multiple file groups
>unless you know you need them.
>If you are using multiple physical disks, SQL Server
>usually does a good job of striping the tables across the
>disks. If you do have one of more large tables that are
>very active it can be a benefit to put the non-clustered
>indexes in a seperate filegroup. Providing that filegroup
>is on different physical drives. I would advise against
>doing it as a matter of course, only do it if you can
>prove it is an issue.
>Hope this helps
>John
>.
>

Primary key question

Hi,

I am new to SQL 2000 and scratching my head...I am importing text files to SQL 2000 tables. How should I define the primary key in a table if the text file is :

Example 'customer invoice file'
column 1-Customer Bus Unit (Char 3)
column 2-Batch number (Char 6)
column 3-Document type (Char 1)
column 4-Invoice number (char 15)
column 5-Invoice dollar (Money)
column 6 - due date (date)
column 7 - customer name (char 35)
column 8 - customer address (char 50)

The primary key of this file is column1 + column 2 + coumn 3 + column 4. That concatnation of 4 fields make each record unique.
Should I define all 4 feilds as the primary key field? Thank you, Yanoroouh...yes...

Do you have a staging environemnt?

You can create work tables with no constraints...that way you can audit the data before it hit the final destination...|||Originally posted by Brett Kaiser
uh...yes...

Do you have a staging environemnt?

You can create work tables with no constraints...that way you can audit the data before it hit the final destination...

Please bear with me...
What do you mean a staging environment?
Could you suggest a work table design? (example)|||Sure...it's a table that looks like your final table...just that it has no keys, indexes or other constraints...even make all of the columns varchar (dates, money, ect)

You can the audit the data

LIKE

SELECT * FROM myTable99 WHERE ISDATE(adatecolumn) = 0

Will show you all rows with bad dates

SELECT * FROM myTable99 WHERE ISNUMERIC(anumericcolumn) = 0

Will show you all rows with non numbers in the expected number columns

PK violations

SELECT col1, col2, col3, col4, count(*)
FROM mytable99
GROUP BY col1, col2, col3, col4
HAVING COUNT(*) > 1

Shows where you'll have a dup key

ect

You can even make sure RI is ok...

If the data passes your audit, you can either bcp/dts or bulk insert the file, or Just INSERT it from your stage table...

Clear as mud?

Let me know...|||Okay, I will try that. Thank you very much.
I may encounter another questions... I will let you know.
Yanoroo|||Brett, are you still checking?
Not only the staging the work, I tried your PK violation check and it worked beautifully.
I appriciate your help. Yanoroo|||Hey....Merry Holiday

I'm glad it worked for you...It's always better to know that you're working with clean data...

TRUST NO ONE bearing Excel spreadsheets...(or other data sources outside your environment)..
Better still require data files with header and/or trailers...and if you can only get one...demand a trailer...with record counts and possible the sum of int/decimal columns...

Primary FilesGroup change path

I want modify the path Files of 'Primary' FilesGroup when DataBase is create.

The smo create a default 'primary' FilesGroup when DataBase.Create().

After database is create the path 'primary' FilesGroup' was not change.

Thats possible?

Dim srv as new Server ("SQL instance")

Dim db as new DataBase (srv,"DataBaseTest")

--> how code for modify the FilesGroup 'primary' and the files path?

db.create()

Thanks,

Marsenne

This code below sucessfuly. Create a DataBase in another path (files)

- create a path first (D:\SqlBancos\Teste) with 'primaryroot' databases base.

Dim srv As New Server(Me.cmbSqlServer.Text)

Dim db As New Database(srv, "Teste")

db.DatabaseOptions.AutoShrink = True

db.FileGroups.Add(New FileGroup(db, "PRIMARY"))

db.FileGroups(0).Files.Add(New DataFile(db.FileGroups(0), "TestName", "D:\SqlBancos\Teste\Teste1.mdf"))

db.Create()

db.Alter()

Marsenne Negreiros

PRIMARY Files

Taking a course on SQL. They are saying you can get better performance by
having multiple files for a group.

They then graphically show an example of "Primary" with multiple data files.

I have tried altering PRIMARY to have multiple data files and I get and
error. I have tried creating a new database with multiple PRIMARY files and
get an error.

I can ALTER and CREATE secondary files with multiple data files with no
problem.

Am I mixing apples with oranges, does their "Primary" mean something
different then "PRIMARY"?

Looking at help it seems that you can only have one PRIMARY data file and I
am thinking their use of "Primary" means the primary group where you will
have your tables, not the PRIMARY group. Just don't want to lock onto the
wrong concept.

Thank you101 wrote:
> Taking a course on SQL. They are saying you can get better performance by
> having multiple files for a group.
> They then graphically show an example of "Primary" with multiple data files.
> I have tried altering PRIMARY to have multiple data files and I get and
> error. I have tried creating a new database with multiple PRIMARY files and
> get an error.
> I can ALTER and CREATE secondary files with multiple data files with no
> problem.
> Am I mixing apples with oranges, does their "Primary" mean something
> different then "PRIMARY"?
> Looking at help it seems that you can only have one PRIMARY data file and I
> am thinking their use of "Primary" means the primary group where you will
> have your tables, not the PRIMARY group. Just don't want to lock onto the
> wrong concept.

Read the BOL article "Creating Filegroups." There can be only ONE
Primary file group. There are 3 types of file groups: Primary, User
Defined, Default (usually the Primary file group).
--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)|||Oops, I think I got it. Each time you create a database you can specify the
location of it's PRIMARY file. Each database in an instance can have it's
PRIMARY data file pointing to a different data file. Therefore the PRIMARY
group can have multiple data files. But you can't have multiple data files
for a single database in the PRIMARY group.

Am I warm?
"101" <AceMagoo61@.yahoo.com> wrote in message
news:a9yce.11088$XF3.8443@.twister.nyroc.rr.com...
> Taking a course on SQL. They are saying you can get better performance by
> having multiple files for a group.
> They then graphically show an example of "Primary" with multiple data
> files.
> I have tried altering PRIMARY to have multiple data files and I get and
> error. I have tried creating a new database with multiple PRIMARY files
> and get an error.
> I can ALTER and CREATE secondary files with multiple data files with no
> problem.
> Am I mixing apples with oranges, does their "Primary" mean something
> different then "PRIMARY"?
> Looking at help it seems that you can only have one PRIMARY data file and
> I am thinking their use of "Primary" means the primary group where you
> will have your tables, not the PRIMARY group. Just don't want to lock onto
> the wrong concept.
> Thank you|||101 wrote:
> I understand that there can be only one PRIMARY group. Where I am getting confused is how many data files can there be for one database within the PRIMARY group.
> I am thinking I can have this:
> MyDb_Primary 1 d:\mssql\data\MyDB_Pri.mdf PRIMARY 640 KB Unlimited 10% data only
> MyDB_FG_Dat1 3 e:\mssql\data\MyDB_FG1_1.ndf MyDB_FG1 1024 KB Unlimited 10% data only
> MyDB_FG_Dat2 4 f:\mssql\data\MyDB_FG2_2.ndf MyDB_FG1 1024 KB Unlimited 10% data only
> But I can't have this:
> MyDb_Prim_1 1 d:\mssql\data\MyDB_Pri_1.mdf PRIMARY 640 KB Unlimited 10% data only
> MyDB_Prim_2 3 e:\mssql\data\MyDB_Pri_2.ndf PRIMARY 1024 KB Unlimited 10% data only
> MyDB_Prim_3 4 f:\mssql\data\MyDB_Pri_3.ndf PRIMARY 1024 KB Unlimited 10% data only

That is my understanding also.

--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)|||Hi,

I believe what you are looking for is the following command which adds
another file to the PRIMARY filegroup:

ALTER DATABASE FileGroupTest
ADD FILE
(
NAME = FileGroupTest2,
FILENAME = 'c:\FileGroupTestData2.ndf',
SIZE = 5MB,
MAXSIZE = 100MB,
FILEGROWTH = 5MB
)

This is a cut n paste from Books Online.|||101 (AceMagoo61@.yahoo.com) writes:
> Oops, I think I got it. Each time you create a database you can specify
> the location of it's PRIMARY file. Each database in an instance can have
> it's PRIMARY data file pointing to a different data file. Therefore the
> PRIMARY group can have multiple data files. But you can't have multiple
> data files for a single database in the PRIMARY group.

No, that's not correct. Filegroups do not span databases. In fact
there is no storage entity in SQL Server 7 and later which spans databases.
(In SQL 6.5 and earlier there was, as you always created databases on
devices.)

This is it: a database has one primary file and one primary file group.
The primary file group can contain several files, but only one is the
primary file. The primary file contains sysfiles, which holds information
about all other files and filegroups in the database. (At least this is
my understanding, after reading Kalen Delaney's "Inside SQL Server 2000".)

Here is an example that creates multiple files in the primary file group:

CREATE DATABASE multifile ON
(NAME = multifile_prim1,
filename = 'F:\mssql\data\multifile_1.mdf'),
(NAME = multifile_prim2,
filename = 'F:\mssql\data\multifile_2.mdf'),
FILEGROUP SECONDARY
(NAME = multifile_sec1,
filename = 'F:\mssql\data\multifile_1.ndf'),
(NAME = multifile_sec2,
filename = 'F:\mssql\data\multifile_2.ndf')
LOG ON
(NAME = multifile_log1,
filename = 'F:\mssql\data\multifile_1.ldf'),
(NAME = multifile_log2,
filename = 'F:\mssql\data\multifile_2.ldf')
go
exec sp_helpdb multifile

Note that the syntax in Books Online is apparently wrong. It goes:

CREATE DATABASE database_name
[ ON
[ < filespec > [ ,...n ] ]
[ , < filegroup > [ ,...n ] ]
]
[ LOG ON { < filespec > [ ,...n ] } ]
[ COLLATE collation_name ]
[ FOR LOAD | FOR ATTACH ]

< filespec > ::=
[ PRIMARY ]
( [ NAME = logical_file_name , ]
FILENAME = 'os_file_name'
[ , SIZE = size ]
[ , MAXSIZE = { max_size | UNLIMITED } ]
[ , FILEGROWTH = growth_increment ] ) [ ,...n ]

< filegroup > ::=

FILEGROUP filegroup_name < filespec > [ ,...n ]

But you cannot have FILEGROUP directly after ON. And you cannot use
PRIMARY in a <filespec> which is part of a FILEGROUP definition.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Ok,
I guess I was paying the learning sin-tax. I was trying this:
ALTER DATABASE FileGroupTest
ADD FILE
( NAME = FGT_Pri5,
FILENAME ='c:\mssql\data\FGT_Pri5.ndf'
)
TO FILEGROUP PRIMARY
Which of course errors. I guess the rule is if adding to the PRIMARY group
you don't use the FILEGROUP statement, it will default to the PRIMARY group.
You only use the FILEGROUP statement when adding a file to a user group.

Thank you
"Malcolm" <malcolm.leach@.innovartis.co.uk> wrote in message
news:1114849361.130062.105130@.g14g2000cwa.googlegr oups.com...
> Hi,
> I believe what you are looking for is the following command which adds
> another file to the PRIMARY filegroup:
> ALTER DATABASE FileGroupTest
> ADD FILE
> (
> NAME = FileGroupTest2,
> FILENAME = 'c:\FileGroupTestData2.ndf',
> SIZE = 5MB,
> MAXSIZE = 100MB,
> FILEGROWTH = 5MB
> )
> This is a cut n paste from Books Online.|||Ok, thank you. My problem was I had incorrect syntax trying to add files to
the PRIMARY group.

My understanding is one reason to have multiple files within a file group is
to allow SQL to stripe the data.

Now northwind has only one file (besides the log), northwind.mdf. So
sysfiles and along with everything else reside in that one file. What
happens when I add files to the PRIMARY group for the database?

a) sysfiles stay on northwind.mdf and the rest of the data is spread accross
northwind.mdf, northwind2.ndf, northwind3.ndf.

or

b) sysfiles stay on northwind.mdf and everything else is spread accross
northwind2.ndf and northwind3.ndf.

or

c) ??

Also

I notices that the second file you defined for primary had an extention of
..mdf, is that the common practice? .mdf files defined to the primary group
and .ndf files get defined in user groups?
I was defining the first file allocated to a group as .mdf and subsequent
files as .ndf regardless if they were in the PRIMARY group or a USER group.
It looks like you can do both, then again I haven't gone far enough to get
bitten. Even if you can get away with both practices, is there a common
practice for when you define a file with a .mdf extention and a .ndf
extention?

Don't mean to be a pain, just interested in the right way of doing things
and following good procedures.

"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9648B2C5E59D8Yazorman@.127.0.0.1...
> 101 (AceMagoo61@.yahoo.com) writes:
>> Oops, I think I got it. Each time you create a database you can specify
>> the location of it's PRIMARY file. Each database in an instance can have
>> it's PRIMARY data file pointing to a different data file. Therefore the
>> PRIMARY group can have multiple data files. But you can't have multiple
>> data files for a single database in the PRIMARY group.
> No, that's not correct. Filegroups do not span databases. In fact
> there is no storage entity in SQL Server 7 and later which spans
> databases.
> (In SQL 6.5 and earlier there was, as you always created databases on
> devices.)
> This is it: a database has one primary file and one primary file group.
> The primary file group can contain several files, but only one is the
> primary file. The primary file contains sysfiles, which holds information
> about all other files and filegroups in the database. (At least this is
> my understanding, after reading Kalen Delaney's "Inside SQL Server 2000".)
> Here is an example that creates multiple files in the primary file group:
> CREATE DATABASE multifile ON
> (NAME = multifile_prim1,
> filename = 'F:\mssql\data\multifile_1.mdf'),
> (NAME = multifile_prim2,
> filename = 'F:\mssql\data\multifile_2.mdf'),
> FILEGROUP SECONDARY
> (NAME = multifile_sec1,
> filename = 'F:\mssql\data\multifile_1.ndf'),
> (NAME = multifile_sec2,
> filename = 'F:\mssql\data\multifile_2.ndf')
> LOG ON
> (NAME = multifile_log1,
> filename = 'F:\mssql\data\multifile_1.ldf'),
> (NAME = multifile_log2,
> filename = 'F:\mssql\data\multifile_2.ldf')
> go
> exec sp_helpdb multifile
> Note that the syntax in Books Online is apparently wrong. It goes:
> CREATE DATABASE database_name
> [ ON
> [ < filespec > [ ,...n ] ]
> [ , < filegroup > [ ,...n ] ]
> ]
> [ LOG ON { < filespec > [ ,...n ] } ]
> [ COLLATE collation_name ]
> [ FOR LOAD | FOR ATTACH ]
> < filespec > ::=
> [ PRIMARY ]
> ( [ NAME = logical_file_name , ]
> FILENAME = 'os_file_name'
> [ , SIZE = size ]
> [ , MAXSIZE = { max_size | UNLIMITED } ]
> [ , FILEGROWTH = growth_increment ] ) [ ,...n ]
> < filegroup > ::=
> FILEGROUP filegroup_name < filespec > [ ,...n ]
> But you cannot have FILEGROUP directly after ON. And you cannot use
> PRIMARY in a <filespec> which is part of a FILEGROUP definition.
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techin.../2000/books.asp|||101 (AceMagoo61@.yahoo.com) writes:
> My understanding is one reason to have multiple files within a file
> group is to allow SQL to stripe the data.

Hm, yes, but striping is probably best done by hardware.

Kalen Delaney discusses this in her book a bit, and she puts more
stress on flexibility. If you have a 60 GB database in one file and
you need to restore it, you need to find 60 GB of free space on one
disk. If you have three files, you can combine space on more than
one disk.

> Now northwind has only one file (besides the log), northwind.mdf. So
> sysfiles and along with everything else reside in that one file. What
> happens when I add files to the PRIMARY group for the database?
> a) sysfiles stay on northwind.mdf and the rest of the data is spread
> accross northwind.mdf, northwind2.ndf, northwind3.ndf.

As I understand it, all system tables are in the primary file. The
user table and indexes are spread over the other filers, including
northwind.mdf.

> I notices that the second file you defined for primary had an extention of
> .mdf, is that the common practice? .mdf files defined to the primary group
> and .ndf files get defined in user groups?

It appears that I've should have used .ndf for the second file, and
not .mdf. I rarely play with multiple files, so I just made a guess
that .ndf for files in other file groups, but I was wong.

In any case, that is just a convention and you can use .doc and .xls if
you feel like. (But I would not recommend using precisely those
exetentions!)

> Even if you can get away with both practices, is there a common
> practice for when you define a file with a .mdf extention and a .ndf
> extention?

The practice appears to be .mdf for primary files and .ndf for secondary.
And .ldf for log files. But I would not be surprised if there are shops
where they have multiple files and they use .mdf for all data files.
I would suggest that the main thing here is that you is consistent, and
don't mix different styles. (I actually had this database with a log
file with .mdf. It caused me some problems when I tried to restore
a backup of the database in the SQL 2005 GUI, and I submitted a bug
report, because the GUI used the same file name for both. I thought
the GUI was crappy because it used .mdf for the log file. It took me
quite some time, to see that it was my own mistake.)

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Thank you!
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9648C89CCC942Yazorman@.127.0.0.1...
> 101 (AceMagoo61@.yahoo.com) writes:
>> My understanding is one reason to have multiple files within a file
>> group is to allow SQL to stripe the data.
> Hm, yes, but striping is probably best done by hardware.
> Kalen Delaney discusses this in her book a bit, and she puts more
> stress on flexibility. If you have a 60 GB database in one file and
> you need to restore it, you need to find 60 GB of free space on one
> disk. If you have three files, you can combine space on more than
> one disk.
>> Now northwind has only one file (besides the log), northwind.mdf. So
>> sysfiles and along with everything else reside in that one file. What
>> happens when I add files to the PRIMARY group for the database?
>>
>> a) sysfiles stay on northwind.mdf and the rest of the data is spread
>> accross northwind.mdf, northwind2.ndf, northwind3.ndf.
> As I understand it, all system tables are in the primary file. The
> user table and indexes are spread over the other filers, including
> northwind.mdf.
>> I notices that the second file you defined for primary had an extention
>> of
>> .mdf, is that the common practice? .mdf files defined to the primary
>> group
>> and .ndf files get defined in user groups?
> It appears that I've should have used .ndf for the second file, and
> not .mdf. I rarely play with multiple files, so I just made a guess
> that .ndf for files in other file groups, but I was wong.
> In any case, that is just a convention and you can use .doc and .xls if
> you feel like. (But I would not recommend using precisely those
> exetentions!)
>> Even if you can get away with both practices, is there a common
>> practice for when you define a file with a .mdf extention and a .ndf
>> extention?
> The practice appears to be .mdf for primary files and .ndf for secondary.
> And .ldf for log files. But I would not be surprised if there are shops
> where they have multiple files and they use .mdf for all data files.
> I would suggest that the main thing here is that you is consistent, and
> don't mix different styles. (I actually had this database with a log
> file with .mdf. It caused me some problems when I tried to restore
> a backup of the database in the SQL 2005 GUI, and I submitted a bug
> report, because the GUI used the same file name for both. I thought
> the GUI was crappy because it used .mdf for the log file. It took me
> quite some time, to see that it was my own mistake.)
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server SP3 at
> http://www.microsoft.com/sql/techin.../2000/books.asp

primary filegroup with 2 files

We have the Primary filegroup thats tied to 2 physical files situated on X
and Y drive.
Both X and Y drive have enough free space.
So my question is ,
Is there a possibility where a table i.e. its data and index pages may be
shared across these 2 files ? If so, would there be a performance
degradation to such a setup ?
I am using SQL 2000
ThanksThere is much more than a possibility that data is spread across the files.
Tables and indexes are placed on filegroups, not files, and if the filegroup
has multiple files, SQL Server will always spread the data evenly (or it
will attempt to make it as even as possible) across all the files in the
filegroup.
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:OOaa#tgVDHA.1928@.TK2MSFTNGP12.phx.gbl...
> We have the Primary filegroup thats tied to 2 physical files situated on X
> and Y drive.
> Both X and Y drive have enough free space.
> So my question is ,
> Is there a possibility where a table i.e. its data and index pages may be
> shared across these 2 files ? If so, would there be a performance
> degradation to such a setup ?
> I am using SQL 2000
> Thanks
>|||This is a multi-part message in MIME format.
--=_NextPart_000_0286_01C355EB.275AE650
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Most likely, your tables/indexes are spread across both files. Since =the files are on two different drives, you will likely see a performance =benefit.
-- Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Hassan" <fatima_ja@.hotmail.com> wrote in message =news:OOaa#tgVDHA.1928@.TK2MSFTNGP12.phx.gbl...
We have the Primary filegroup thats tied to 2 physical files situated on =X
and Y drive.
Both X and Y drive have enough free space.
So my question is ,
Is there a possibility where a table i.e. its data and index pages may =be
shared across these 2 files ? If so, would there be a performance
degradation to such a setup ?
I am using SQL 2000
Thanks
--=_NextPart_000_0286_01C355EB.275AE650
Content-Type: text/html;
charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

---

Most likely, your tables/indexes are =spread across both files. Since the files are on two different drives, you will =likely see a performance benefit.
-- Tom
---T=homas A. Moreau, BSc, PhD, MCSE, MCDBASQL Server MVPColumnist, SQL =Server ProfessionalToronto, ON Canadahttp://www.pinnaclepublishing.com/sql">www.pinnaclepublishing.com=/sql
"Hassan" =wrote in message news:OOaa#tgVDHA.1928=@.TK2MSFTNGP12.phx.gbl...We have the Primary filegroup thats tied to 2 physical files situated on =Xand Y drive.Both X and Y drive have enough free space.So my =question is ,Is there a possibility where a table i.e. its data and index =pages may beshared across these 2 files ? If so, would there be a performancedegradation to such a setup ?I am using SQL 2000Thanks

---

--=_NextPart_000_0286_01C355EB.275AE650--|||So a table thats spread across 2 drives and I query from it, wouldnt there
be some performance hit maybe. It may be faster to read from one drive as
opposed to 2 drive as in different RAID Channels. and then aggregating them
..dont u think ?
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:eLJD#ygVDHA.384@.TK2MSFTNGP12.phx.gbl...
Most likely, your tables/indexes are spread across both files. Since the
files are on two different drives, you will likely see a performance
benefit.
--
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:OOaa#tgVDHA.1928@.TK2MSFTNGP12.phx.gbl...
We have the Primary filegroup thats tied to 2 physical files situated on X
and Y drive.
Both X and Y drive have enough free space.
So my question is ,
Is there a possibility where a table i.e. its data and index pages may be
shared across these 2 files ? If so, would there be a performance
degradation to such a setup ?
I am using SQL 2000
Thanks|||This is a multi-part message in MIME format.
--=_NextPart_000_0062_01C35604.25C48580
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
No. If you have 2 spindles, you potentially can get twice the =throughput than having only one. This is well known.
-- Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
.
"Hassan" <fatima_ja@.hotmail.com> wrote in message =news:eMXEgTiVDHA.2024@.TK2MSFTNGP12.phx.gbl...
So a table thats spread across 2 drives and I query from it, wouldnt =there
be some performance hit maybe. It may be faster to read from one drive =as
opposed to 2 drive as in different RAID Channels. and then aggregating =them
..dont u think ?
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:eLJD#ygVDHA.384@.TK2MSFTNGP12.phx.gbl...
Most likely, your tables/indexes are spread across both files. Since =the
files are on two different drives, you will likely see a performance
benefit.
--
Tom
---
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:OOaa#tgVDHA.1928@.TK2MSFTNGP12.phx.gbl...
We have the Primary filegroup thats tied to 2 physical files situated on =X
and Y drive.
Both X and Y drive have enough free space.
So my question is ,
Is there a possibility where a table i.e. its data and index pages may =be
shared across these 2 files ? If so, would there be a performance
degradation to such a setup ?
I am using SQL 2000
Thanks
--=_NextPart_000_0062_01C35604.25C48580
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&

---

No. If you have 2 spindles, you =potentially can get twice the throughput than having only one. This is well known.
-- Tom
----Thomas A. =Moreau, BSc, PhD, MCSE, MCDBASQL Server MVPColumnist, SQL Server ProfessionalToronto, ON Canadahttp://www.pinnaclepublishing.com/sql">www.pinnaclepublishing.com=/sql.
"Hassan" =wrote in message news:eMXEgTiVDHA.2024=@.TK2MSFTNGP12.phx.gbl...So a table thats spread across 2 drives and I query from it, wouldnt =therebe some performance hit maybe. It may be faster to read from one drive asopposed to 2 drive as in different RAID Channels. and then =aggregating them..dont u think ?"Tom Moreau" = wrote in messagenews:eLJD#ygVDHA.384@.T=K2MSFTNGP12.phx.gbl...Most likely, your tables/indexes are spread across both files. Since thefiles are on two different drives, you will likely see a performancebenefit.--Tom--=---Thomas A. Moreau, BSc, PhD, MCSE, MCDBASQL Server MVPColumnist, SQL =Server ProfessionalToronto, ON Canadahttp://www.pinnaclepublishing.com/sql">www.pinnaclepublishing.com=/sql"Hassan" =wrote in messagenews:OOaa#tgVDHA.1928=@.TK2MSFTNGP12.phx.gbl...We have the Primary filegroup thats tied to 2 physical files situated on =Xand Y drive.Both X and Y drive have enough free space.So my =question is ,Is there a possibility where a table i.e. its data and index =pages may beshared across these 2 files ? If so, would there be a performancedegradation to such a setup ?I am using SQL 2000Thanks

---

--=_NextPart_000_0062_01C35604.25C48580--

Primary file group full

I have inherited a SQL server 2000 DB where the system and user tables
are separated into different mdf files (on separate drives). The
primary file group is the system data. I have a query that is
returning data from a remote DB table which is not in the local DB
table. I am running to the problem that as the query is running the
primary file group is now full. I have rebuilt the indexes and run a
shrink of the db, but still the file group is full. I have auto
growth enabled to unrestricted, but am getting an ERROR 1827. Any
help is greatly appreciated!
Daniel
Hi
And do you have enough space on the disk? I have seen such errors , it
could happen what the database tried to grow and while it is growing (writes
zeroes to the pages) users get the error.
"danielp" <danielsmith611@.gmail.com> wrote in message
news:1172157667.706350.173350@.q2g2000cwa.googlegro ups.com...
>I have inherited a SQL server 2000 DB where the system and user tables
> are separated into different mdf files (on separate drives). The
> primary file group is the system data. I have a query that is
> returning data from a remote DB table which is not in the local DB
> table. I am running to the problem that as the query is running the
> primary file group is now full. I have rebuilt the indexes and run a
> shrink of the db, but still the file group is full. I have auto
> growth enabled to unrestricted, but am getting an ERROR 1827. Any
> help is greatly appreciated!
> Daniel
>

Primary file group full

I have inherited a SQL server 2000 DB where the system and user tables
are separated into different mdf files (on separate drives). The
primary file group is the system data. I have a query that is
returning data from a remote DB table which is not in the local DB
table. I am running to the problem that as the query is running the
primary file group is now full. I have rebuilt the indexes and run a
shrink of the db, but still the file group is full. I have auto
growth enabled to unrestricted, but am getting an ERROR 1827. Any
help is greatly appreciated!
DanielHi
And do you have enough space on the disk? I have seen such errors , it
could happen what the database tried to grow and while it is growing (writes
zeroes to the pages) users get the error.
"danielp" <danielsmith611@.gmail.com> wrote in message
news:1172157667.706350.173350@.q2g2000cwa.googlegroups.com...
>I have inherited a SQL server 2000 DB where the system and user tables
> are separated into different mdf files (on separate drives). The
> primary file group is the system data. I have a query that is
> returning data from a remote DB table which is not in the local DB
> table. I am running to the problem that as the query is running the
> primary file group is now full. I have rebuilt the indexes and run a
> shrink of the db, but still the file group is full. I have auto
> growth enabled to unrestricted, but am getting an ERROR 1827. Any
> help is greatly appreciated!
> Daniel
>

Primary file group full

I have inherited a SQL server 2000 DB where the system and user tables
are separated into different mdf files (on separate drives). The
primary file group is the system data. I have a query that is
returning data from a remote DB table which is not in the local DB
table. I am running to the problem that as the query is running the
primary file group is now full. I have rebuilt the indexes and run a
shrink of the db, but still the file group is full. I have auto
growth enabled to unrestricted, but am getting an ERROR 1827. Any
help is greatly appreciated!
DanielHi
And do you have enough space on the disk? I have seen such errors , it
could happen what the database tried to grow and while it is growing (writes
zeroes to the pages) users get the error.
"danielp" <danielsmith611@.gmail.com> wrote in message
news:1172157667.706350.173350@.q2g2000cwa.googlegroups.com...
>I have inherited a SQL server 2000 DB where the system and user tables
> are separated into different mdf files (on separate drives). The
> primary file group is the system data. I have a query that is
> returning data from a remote DB table which is not in the local DB
> table. I am running to the problem that as the query is running the
> primary file group is now full. I have rebuilt the indexes and run a
> shrink of the db, but still the file group is full. I have auto
> growth enabled to unrestricted, but am getting an ERROR 1827. Any
> help is greatly appreciated!
> Daniel
>

Preventing driver from creating nuisance temp files

Hi,
I am using the Microsoft SQL Server 2000 Driver for JDBC, Service Pack 2,
Version 2.2.0037 with windows XP and j2sdk1.4.2_03.
I am having trouble with the driver creating huge numbers of temporary files
and never deleting them.
Each time I call the getPrimaryKeys(catalog, schema, table) method of the
DatabaseMetaData class I get two temperary file saved to the windows
temporary directory, a srt_XXXXX.tmp and a scb_YYYYY.tmp (XXXXX and YYYYY are
numbers).
The code I am using is as follows;
try {
Class.forName(com.microsoft.jdbc.sqlserver.SQLServ erDriver);
}
catch (ClassNotFoundException ce) {
}
Connection con;
con =
DriverManager.getConnection(jdbc:microsoft:sqlserv er://Server1:1433;SelectMethod=cursor;DatabaseName=data base1, user, passwd);
DatabaseMetaData md = con.getMetaData();
String catalog = null;
String schema = null;
String table = "table1";
ResultSet rs = rs = md.getPrimaryKeys(catalog, schema, tables);
The scb file is empty and the srt file always containes the same binary
number 00 00 00 01. These files are never deleted and quickly build up to
many thousands of files.
Can anybody suggest how to prevent these files from being created?
Any assistance would be much appreciated.
Regards,
Ian555
| Thread-Topic: Preventing driver from creating nuisance temp files
| thread-index: AcS7DnlA9D48A8QHSk6192TimiCXsQ==
| X-WBNR-Posting-Host: 203.59.26.12
| From: =?Utf-8?B?SWFuNTU1?= <Ian555@.discussions.microsoft.com>
| Subject: Preventing driver from creating nuisance temp files
| Date: Mon, 25 Oct 2004 20:47:11 -0700
| Lines: 43
| Message-ID: <248D2293-B2AF-4FF0-B5E2-DB42E12357DD@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.sqlserver.jdbcdriver
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
| Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.jdbcdriver:6419
| X-Tomcat-NG: microsoft.public.sqlserver.jdbcdriver
|
| Hi,
|
| I am using the Microsoft SQL Server 2000 Driver for JDBC, Service Pack 2,
| Version 2.2.0037 with windows XP and j2sdk1.4.2_03.
|
| I am having trouble with the driver creating huge numbers of temporary
files
| and never deleting them.
|
| Each time I call the getPrimaryKeys(catalog, schema, table) method of the
| DatabaseMetaData class I get two temperary file saved to the windows
| temporary directory, a srt_XXXXX.tmp and a scb_YYYYY.tmp (XXXXX and YYYYY
are
| numbers).
|
| The code I am using is as follows;
|
| try {
| Class.forName(com.microsoft.jdbc.sqlserver.SQLServ erDriver);
| }
| catch (ClassNotFoundException ce) {
| }
| Connection con;
| con =
|
DriverManager.getConnection(jdbc:microsoft:sqlserv er://Server1:1433;SelectMe
thod=cursor;DatabaseName=database1, user, passwd);
|
| DatabaseMetaData md = con.getMetaData();
|
| String catalog = null;
| String schema = null;
| String table = "table1";
|
| ResultSet rs = rs = md.getPrimaryKeys(catalog, schema, tables);
|
| The scb file is empty and the srt file always containes the same binary
| number 00 00 00 01. These files are never deleted and quickly build up
to
| many thousands of files.
|
| Can anybody suggest how to prevent these files from being created?
|
| Any assistance would be much appreciated.
|
| Regards,
|
| Ian555
|
Hello,
We are going to investigate this problem and post back the results. Thanks
for bringing this to our attention.
Carb Simien, MCSE MCDBA MCAD
Microsoft Developer Support - Web Data
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
|||| X-Tomcat-ID: 447862052
| References: <248D2293-B2AF-4FF0-B5E2-DB42E12357DD@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain
| Content-Transfer-Encoding: 7bit
| From: CarbinoS@.online.microsoft.com ("Carb Simien [MSFT]")
| Organization: Microsoft Corporation
| Date: Tue, 26 Oct 2004 17:41:42 GMT
| Subject: RE: Preventing driver from creating nuisance temp files
| X-Tomcat-NG: microsoft.public.sqlserver.jdbcdriver
| Message-ID: <YIBoRM4uEHA.2092@.cpmsftngxa10.phx.gbl>
| Newsgroups: microsoft.public.sqlserver.jdbcdriver
| Lines: 77
| Path: cpmsftngxa10.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.jdbcdriver:6423
| NNTP-Posting-Host: tomcatimport2.phx.gbl 10.201.218.182
|
|
| --
| | Thread-Topic: Preventing driver from creating nuisance temp files
| | thread-index: AcS7DnlA9D48A8QHSk6192TimiCXsQ==
| | X-WBNR-Posting-Host: 203.59.26.12
| | From: =?Utf-8?B?SWFuNTU1?= <Ian555@.discussions.microsoft.com>
| | Subject: Preventing driver from creating nuisance temp files
| | Date: Mon, 25 Oct 2004 20:47:11 -0700
| | Lines: 43
| | Message-ID: <248D2293-B2AF-4FF0-B5E2-DB42E12357DD@.microsoft.com>
| | MIME-Version: 1.0
| | Content-Type: text/plain;
| | charset="Utf-8"
| | Content-Transfer-Encoding: 7bit
| | X-Newsreader: Microsoft CDO for Windows 2000
| | Content-Class: urn:content-classes:message
| | Importance: normal
| | Priority: normal
| | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| | Newsgroups: microsoft.public.sqlserver.jdbcdriver
| | NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
| | Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
| | Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.jdbcdriver:6419
| | X-Tomcat-NG: microsoft.public.sqlserver.jdbcdriver
| |
| | Hi,
| |
| | I am using the Microsoft SQL Server 2000 Driver for JDBC, Service Pack
2,
| | Version 2.2.0037 with windows XP and j2sdk1.4.2_03.
| |
| | I am having trouble with the driver creating huge numbers of temporary
| files
| | and never deleting them.
| |
| | Each time I call the getPrimaryKeys(catalog, schema, table) method of
the
| | DatabaseMetaData class I get two temperary file saved to the windows
| | temporary directory, a srt_XXXXX.tmp and a scb_YYYYY.tmp (XXXXX and
YYYYY
| are
| | numbers).
| |
| | The code I am using is as follows;
| |
| | try {
| |
Class.forName(com.microsoft.jdbc.sqlserver.SQLServ erDriver);
| | }
| | catch (ClassNotFoundException ce) {
| | }
| | Connection con;
| | con =
| |
|
DriverManager.getConnection(jdbc:microsoft:sqlserv er://Server1:1433;SelectMe
| thod=cursor;DatabaseName=database1, user, passwd);
| |
| | DatabaseMetaData md = con.getMetaData();
| |
| | String catalog = null;
| | String schema = null;
| | String table = "table1";
| |
| | ResultSet rs = rs = md.getPrimaryKeys(catalog, schema, tables);
| |
| | The scb file is empty and the srt file always containes the same binary
| | number 00 00 00 01. These files are never deleted and quickly build up
| to
| | many thousands of files.
| |
| | Can anybody suggest how to prevent these files from being created?
| |
| | Any assistance would be much appreciated.
| |
| | Regards,
| |
| | Ian555
| |
|
| Hello,
|
| We are going to investigate this problem and post back the results.
Thanks
| for bringing this to our attention.
|
| Carb Simien, MCSE MCDBA MCAD
| Microsoft Developer Support - Web Data
|
| Please reply only to the newsgroups.
| This posting is provided "AS IS" with no warranties, and confers no
rights.
|
| Are you secure? For information about the Strategic Technology
Protection
| Program and to order your FREE Security Tool Kit, please visit
| http://www.microsoft.com/security.
|
|
Hello,
Are you closing your ResultSet in your repro code? If I close the
ResultSet in my test, then the files are not left over any more. Please
post back indicating whether or not this changes the behavior.
Carb Simien, MCSE MCDBA MCAD
Microsoft Developer Support - Web Data
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.
|||Hi Carb,
Yes, explicitly closing the resultset has prevented the temp files from
remaining in the windows temp directory.
Thank you for your assistance with this problem.
Best regards,
Ian
""Carb Simien [MSFT]"" wrote:

> --
> | X-Tomcat-ID: 447862052
> | References: <248D2293-B2AF-4FF0-B5E2-DB42E12357DD@.microsoft.com>
> | MIME-Version: 1.0
> | Content-Type: text/plain
> | Content-Transfer-Encoding: 7bit
> | From: CarbinoS@.online.microsoft.com ("Carb Simien [MSFT]")
> | Organization: Microsoft Corporation
> | Date: Tue, 26 Oct 2004 17:41:42 GMT
> | Subject: RE: Preventing driver from creating nuisance temp files
> | X-Tomcat-NG: microsoft.public.sqlserver.jdbcdriver
> | Message-ID: <YIBoRM4uEHA.2092@.cpmsftngxa10.phx.gbl>
> | Newsgroups: microsoft.public.sqlserver.jdbcdriver
> | Lines: 77
> | Path: cpmsftngxa10.phx.gbl
> | Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.jdbcdriver:6423
> | NNTP-Posting-Host: tomcatimport2.phx.gbl 10.201.218.182
> |
> |
> | --
> | | Thread-Topic: Preventing driver from creating nuisance temp files
> | | thread-index: AcS7DnlA9D48A8QHSk6192TimiCXsQ==
> | | X-WBNR-Posting-Host: 203.59.26.12
> | | From: =?Utf-8?B?SWFuNTU1?= <Ian555@.discussions.microsoft.com>
> | | Subject: Preventing driver from creating nuisance temp files
> | | Date: Mon, 25 Oct 2004 20:47:11 -0700
> | | Lines: 43
> | | Message-ID: <248D2293-B2AF-4FF0-B5E2-DB42E12357DD@.microsoft.com>
> | | MIME-Version: 1.0
> | | Content-Type: text/plain;
> | | charset="Utf-8"
> | | Content-Transfer-Encoding: 7bit
> | | X-Newsreader: Microsoft CDO for Windows 2000
> | | Content-Class: urn:content-classes:message
> | | Importance: normal
> | | Priority: normal
> | | X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
> | | Newsgroups: microsoft.public.sqlserver.jdbcdriver
> | | NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
> | | Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
> | | Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.jdbcdriver:6419
> | | X-Tomcat-NG: microsoft.public.sqlserver.jdbcdriver
> | |
> | | Hi,
> | |
> | | I am using the Microsoft SQL Server 2000 Driver for JDBC, Service Pack
> 2,
> | | Version 2.2.0037 with windows XP and j2sdk1.4.2_03.
> | |
> | | I am having trouble with the driver creating huge numbers of temporary
> | files
> | | and never deleting them.
> | |
> | | Each time I call the getPrimaryKeys(catalog, schema, table) method of
> the
> | | DatabaseMetaData class I get two temperary file saved to the windows
> | | temporary directory, a srt_XXXXX.tmp and a scb_YYYYY.tmp (XXXXX and
> YYYYY
> | are
> | | numbers).
> | |
> | | The code I am using is as follows;
> | |
> | | try {
> | |
> Class.forName(com.microsoft.jdbc.sqlserver.SQLServ erDriver);
> | | }
> | | catch (ClassNotFoundException ce) {
> | | }
> | | Connection con;
> | | con =
> | |
> |
> DriverManager.getConnection(jdbc:microsoft:sqlserv er://Server1:1433;SelectMe
> | thod=cursor;DatabaseName=database1, user, passwd);
> | |
> | | DatabaseMetaData md = con.getMetaData();
> | |
> | | String catalog = null;
> | | String schema = null;
> | | String table = "table1";
> | |
> | | ResultSet rs = rs = md.getPrimaryKeys(catalog, schema, tables);
> | |
> | | The scb file is empty and the srt file always containes the same binary
> | | number 00 00 00 01. These files are never deleted and quickly build up
> | to
> | | many thousands of files.
> | |
> | | Can anybody suggest how to prevent these files from being created?
> | |
> | | Any assistance would be much appreciated.
> | |
> | | Regards,
> | |
> | | Ian555
> | |
> |
> | Hello,
> |
> | We are going to investigate this problem and post back the results.
> Thanks
> | for bringing this to our attention.
> |
> | Carb Simien, MCSE MCDBA MCAD
> | Microsoft Developer Support - Web Data
> |
> | Please reply only to the newsgroups.
> | This posting is provided "AS IS" with no warranties, and confers no
> rights.
> |
> | Are you secure? For information about the Strategic Technology
> Protection
> | Program and to order your FREE Security Tool Kit, please visit
> | http://www.microsoft.com/security.
> |
> |
> Hello,
> Are you closing your ResultSet in your repro code? If I close the
> ResultSet in my test, then the files are not left over any more. Please
> post back indicating whether or not this changes the behavior.
> Carb Simien, MCSE MCDBA MCAD
> Microsoft Developer Support - Web Data
> Please reply only to the newsgroups.
> This posting is provided "AS IS" with no warranties, and confers no rights.
> Are you secure? For information about the Strategic Technology Protection
> Program and to order your FREE Security Tool Kit, please visit
> http://www.microsoft.com/security.
>