Primary Keys When importing data

I am creating a stored procedure for our SQL server which does the following:
1. Drops a table called 'Teachers'

drop table [users_dd].[dbo].[Teachers]

2. Recreates that table ready for new data like so...

CREATE TABLE [users_dd].[dbo].[Teachers] (
[username] char (30) NOT NULL,
[SL_Teachcode] nvarchar (12) NULL,
[DueDate] smalldatetime DEFAULT GetDate(),
[ID] INT IDENTITY (1,1) PRIMARY KEY NOT NULL)

3. The last step attempts to import new data. I have used the import/export data wizard to create this query to import new data.

select [users].[username], [users].[SL_Teachcode]
from [users]
where [users].[Staff_teaching]=1
order by [users].[SL_Teachcode]

The last step returns an error because the ID field will not accept Nulls. Of course I don't want it to have nulls as this is to be the primary key for this table. What I want is an automatically generated number there but how do I make that happen? I thought it was all in the definition of the field, ie [ID] INT IDENTITY (1,1) PRIMARY KEY NOT NULL). It seems there is something I missing here however.

Can anybody tell me what I doing wrong (or not doing)?

Murrayuse some thing like:

insert into [users_dd].[dbo].[Teachers] (
[username],].[SL_Teachcode])
select [users].[username], [users].[SL_Teachcode]
from [users]
where [users].[Staff_teaching]=1
order by [users].[SL_Teachcode]

tel us if it works
i try it on my side , it works.
Ridwan,,,|||If you do not need transactional recovery during this load you might do one or a combination of the folowing.

Instead of delete the table with corresponding rows, you might truncate it first and then delete it, less logged and faster. If you do drop the table, you can use select into instead of insert as that is minimally logged and faster as well.

HTH|||SELECT INTO is not faster and is not recommended because of concurrency implications. Truncating and then deleting just doesn't make sence. Why not just TRUNCATE?|||select into is not faster than insert into? I beg to differ, as inserts are fully logged they will take longer. They will also bloat your transaction log and if you have to reallocate space on a drive that could really hurt performance and slow things down. With select into there is no question of drive space allocation and it will run faster. Just for kicks I just ran a select into statement for 1.4 million rows, it took 26 seconds. For that same structure and table an insert into took 2 minutes and 54 seconds.

Now, obviously the argument would be the log and possibly the database file was growing in this time span so to make it an even playing field I truncated the table and did it again with no hard drive growth. The insert into only took 15 seconds without the hard drive growth but after a truncate and a drop table the select into only took 9 seconds.

So, I do not see any situation where the insert into is as fast as the select into and you get the bonus of knowing the hard drive will not have to reallocate space for the log file.

Yes, I meant truncate then DROP the table, not delete. Truncate with delete does not make sense, agreed.|||yup, blurred it out too fast :o

rhigdon, you're absolutely right, - did a 1M-row select into in 20 seconds and insert has been running for the past 6 minutes (Personal edition).

Now you got me experimenting with increased preallocated trx. log.

But I also noticed that we're assuming that recovery mode is Simple. Will it be the same difference in speed if I have it set to Full? Well, I'm still waiting on my insert :)|||No problem :)

I would assume so about the full and simple, you can watch that t-log grow by playing with the dbcc sqlperf('logspace') before and after inserts or select into's.|||BTW, do you have your auto-grow settings enabled? Most of our apps here got converted from 6.5 to either directly 2K or to 7.0 then 2K. Since in 6.5 world we didn't have this luxury of auto-growing, once discovered, - we first got relieved, but then started noticing that for 150+ servers we will have to implement space utilization monitors based on activity within each database. And then - react really quickly once the size reaches the disk limitation. So instead we performed a 2-month space growth analysis and pre-estimated potential annual growth for each database. Then we pre-allocated space on both data and trx. log devices and turned off auto-growth feature. Now we can tell with the level of accuracy to +/- 10MB how much disk space will be needed for any given database by the beginning of the next year.|||Thanks Ridwan,
I tried that code and worked fine. I think I went wrong by using the import/exprot data wizard to construct my query. As soon as I did it 'by hand' it worked fine.
Interesting conversation about the difference between select into and insert into. In this example there will never be more than about 90 -100 records so speed is not a big issue to this task as it takes less than a second to run anyhow.
Thank you all for your input... I hope I can return the favour someday.
Murray|||rdjabarov - that sounds pretty interesting, yes, we use auto-grow for everything. I do have a script that uses some stored procs that runs daily to check for free space and alert me if it gets low though.

Primary Key Violation Error in SQL 2005

Hey guys...

I've recently migrated a SQL 2000 db to SQL 2005. There is a table with a defined primary key. In 2000 when I try importing a duplicate record my application would continue and just skip the duplicates. In 2005 I get an error message "Cannot insert duplicate key row in object ... with unique index..." Is there a setting that I can enable/disable to ignore and continue processing when these errors are encountered? I've read a little on "fail package on step failure" but not quite clear on it. Any tips? Thanks alotHey guys...

I've recently migrated a SQL 2000 db to SQL 2005. There is a table with a defined primary key. In 2000 when I try importing a duplicate record my application would continue and just skip the duplicates. In 2005 I get an error message "Cannot insert duplicate key row in object ... with unique index..." Is there a setting that I can enable/disable to ignore and continue processing when these errors are encountered? I've read a little on "fail package on step failure" but not quite clear on it. Any tips? Thanks alot

Thats strange,you should get an error for that in MSSQL 2000 also.|||Can you post DDL (without editing) for the victim table..?

DDL for both tables i.e. table in 2000 & table in 2005.

I used to transfer data, but I didn't face such problem.|||Is it possible that the PK was created with IGNORE_DUP_KEY=ON in 2000, but OFF in 2005?|||Is it possible that the PK was created with IGNORE_DUP_KEY=ON in 2000, but OFF in 2005?

No,that will also give an error of Duplicate key error in your DTS Package execution.|||No,that will also give an error of Duplicate key error in your DTS Package execution.

maybe I am missing something, but I don't see where the kimykimy said they are using DTS for anything. Or are you referring to this statement: "fail package on step failure"?|||maybe I am missing something, but I don't see where the kimykimy said they are using DTS for anything. Or are you referring to this statement: "fail package on step failure"?
exactly ;)|||thanks for your replies. You can ignore my statements on "fail package on step failure." I am not using DTS for the import. Its an insert statement created from a recordset in a vb application.

In SQL 2000 when a duplicate record tries getting inserted it's ignored and moves on to the next record. In SQL 2005 when a duplicate record tries getting inserted I'm getting the "Duplicate Key" error. And the vb code is the same.

Not sure if this helps, but previously this error was resolved by re-restoring the database. Could this be something that was overlooked during the restoration procedure?|||if you are not using DTS, then my previous comment applies. This exact behavior can happen if you have a PK that was created with IGNORE_DUP_KEY=ON (in that case, dupes will be ignored and not inserted).

so check if the PK is IGNORE_DUP_KEY=ON on the 2000 box and IGNORE_DUP_KEY=OFF on the 2005 box.|||I created a new index with the IGNORE_DUP_KEY=ON but when I'm getting an error message "Duplicate Key was ignored" when a dupilcate is encountered.

What I don't understand is I have another table that retreives data in the same method but from a different source without IGNORE_DUP_KEY enabled and it ignores duplicates and continues processing.

Is there a way to ignore this error message from appearing? Thanks|||I created a new index with the IGNORE_DUP_KEY=ON but when I'm getting an error message "Duplicate Key was ignored" when a dupilcate is encountered.

What I don't understand is I have another table that retreives data in the same method but from a different source without IGNORE_DUP_KEY enabled and it ignores duplicates and continues processing.

Is there a way to ignore this error message from appearing? Thanks

Have you created that table in question?If not, then check for any trigger in that existing table...otherwise I think you should get an error ,and thats the way MSSQL works...sql

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 File Group Full?

I'm uploading a table to my Web Hosting Site that has 499 rows (big rows
because they have binary object in them).
After an hour or so of importing using a DTS package, I get the following
error:
Error at Destination for row number 499. could not allocate space for
object 'Pictures' in database "FamPhoto1' because the 'PRIMARY' filegroup is
full.
What could cause this error? All of the space allocations are defined in my
tables? is my web hoster out of space?
Thanks,
G
Chances are the file was simply not big enough to hold the data you were
trying to import. As such it would attempt to autogrow. If the time it
takes to autogrow is longer than the timeout of the client that initiated
the autogrow it will timeout. That may roll back the autogrow and put you
back to where you started. Always ensure you have plenty of free space in
the db before attempting any operation such as that. Manually grow the
file(s) and you should be all set.
Andrew J. Kelly SQL MVP
"G Dean Blake" <gb@.nospam.com> wrote in message
news:eh54jjUMFHA.2604@.TK2MSFTNGP10.phx.gbl...
> I'm uploading a table to my Web Hosting Site that has 499 rows (big rows
> because they have binary object in them).
> After an hour or so of importing using a DTS package, I get the following
> error:
> Error at Destination for row number 499. could not allocate space for
> object 'Pictures' in database "FamPhoto1' because the 'PRIMARY' filegroup
> is full.
> What could cause this error? All of the space allocations are defined in
> my tables? is my web hoster out of space?
> Thanks,
> G
>
|||What I don't understand is ...
The Webhoster set up an empty database for me, just the system tables - no
user tables. I have the database on my computer and it works just fine and,
apparently, all of my tables fit into the primary file group just fine. I'm
using the IMPORT to transfer four tables to the webhoster database. If my
tables have plenty of space to work well and they all fit on my computer,
why is there not enough space on the target computer?
When a table is "imported" to another database, what determines how much
space that table will be allocated?
G
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:uxX0fHVMFHA.1392@.TK2MSFTNGP10.phx.gbl...
> Chances are the file was simply not big enough to hold the data you were
> trying to import. As such it would attempt to autogrow. If the time it
> takes to autogrow is longer than the timeout of the client that initiated
> the autogrow it will timeout. That may roll back the autogrow and put you
> back to where you started. Always ensure you have plenty of free space in
> the db before attempting any operation such as that. Manually grow the
> file(s) and you should be all set.
> --
> Andrew J. Kelly SQL MVP
>
> "G Dean Blake" <gb@.nospam.com> wrote in message
> news:eh54jjUMFHA.2604@.TK2MSFTNGP10.phx.gbl...
>
|||Well it could be that the drive that the primary filegroup is located on for
the Web site is low on space and yours isn't. It could be your db is
slightly different than the one on the web (indexes, size, recovery model
etc). How large is your primary file vs. the one on the web? Did you try
to grow it manually and see if it errors? The amount of space is dependant
mainly on the size and type of data being imported. The indexexing can play
a large roles as well especially if the clustered index is such that it will
cause page splits when you insert.
Andrew J. Kelly SQL MVP
"G Dean Blake" <gb@.nospam.com> wrote in message
news:uRaTXRVMFHA.2252@.TK2MSFTNGP15.phx.gbl...
> What I don't understand is ...
> The Webhoster set up an empty database for me, just the system tables - no
> user tables. I have the database on my computer and it works just fine
> and, apparently, all of my tables fit into the primary file group just
> fine. I'm using the IMPORT to transfer four tables to the webhoster
> database. If my tables have plenty of space to work well and they all fit
> on my computer, why is there not enough space on the target computer?
> When a table is "imported" to another database, what determines how much
> space that table will be allocated?
> G
>
> "Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
> news:uxX0fHVMFHA.1392@.TK2MSFTNGP10.phx.gbl...
>
|||Hi Andrew
I am suffering form the same mesage "PRIMARY File group is full" even though
there is about 20GB of space on my hard drive and the DB is set to Autogrow.
So space is not the issue.
You suggested manually growng the DB, but can you expalin how I would do this.
Cheers
Coburndavis
"Andrew J. Kelly" wrote:

> Well it could be that the drive that the primary filegroup is located on for
> the Web site is low on space and yours isn't. It could be your db is
> slightly different than the one on the web (indexes, size, recovery model
> etc). How large is your primary file vs. the one on the web? Did you try
> to grow it manually and see if it errors? The amount of space is dependant
> mainly on the size and type of data being imported. The indexexing can play
> a large roles as well especially if the clustered index is such that it will
> cause page splits when you insert.
> --
> Andrew J. Kelly SQL MVP
>
> "G Dean Blake" <gb@.nospam.com> wrote in message
> news:uRaTXRVMFHA.2252@.TK2MSFTNGP15.phx.gbl...
>
>
|||> You suggested manually growng the DB, but can you expalin how I would do this.
ALTER DATABASE dbname MODIFY FILE ( NAME = logical_file_name, SIZE = <desired size>)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"COBURNDAVIS" <COBURNDAVIS@.discussions.microsoft.com> wrote in message
news:AF941E5B-58BF-42F5-8100-B7B5517CCAD4@.microsoft.com...[vbcol=seagreen]
> Hi Andrew
> I am suffering form the same mesage "PRIMARY File group is full" even though
> there is about 20GB of space on my hard drive and the DB is set to Autogrow.
> So space is not the issue.
> You suggested manually growng the DB, but can you expalin how I would do this.
> Cheers
> Coburndavis
>
> "Andrew J. Kelly" wrote:
|||If space is NOT an issue and you are truely set to AUTOGROW, then I suspect
you current database size is, hmmm, about, what? 2 GB?
If so, then you are using MSDE and just found one of the restrictions of
that edition. The only known solution is to upgrade to a Server-Class
edition or split your database into multiple databases...hey, just like you
would do with MS Access. Sound familiar? That's why MSDE stands for MS
Desktop Edition, it is a personal replacement or alternative to MS Access,
but not for Server-class, production, Client/Server or n-Tier solutions,
only Standard and Enterprise Editions are, and now, the new Workgroup
Editionalthough, WE has its own restrictions.
Now, the Web Host sounds suspicious. I don't believe anyone would attempt
to run MSDE as a hosted edition. Are you on a dedicated server or are you
sharing? Do you know if the hosted database is set to AUTOGROW or not? Do
you know how much free space is on the drives for the hosted server? Do you
know if the ISP has quotas turned on for you data file foldersusually, you
would get a different error message if this were the case, but I would check
anyway?
Sincerely,
Anthony Thomas

"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:ObeUpDUYFHA.3320@.TK2MSFTNGP12.phx.gbl...
> You suggested manually growng the DB, but can you expalin how I would do
this.
ALTER DATABASE dbname MODIFY FILE ( NAME = logical_file_name, SIZE =
<desired size>)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"COBURNDAVIS" <COBURNDAVIS@.discussions.microsoft.com> wrote in message
news:AF941E5B-58BF-42F5-8100-B7B5517CCAD4@.microsoft.com...
> Hi Andrew
> I am suffering form the same mesage "PRIMARY File group is full" even
though
> there is about 20GB of space on my hard drive and the DB is set to
Autogrow.
> So space is not the issue.
> You suggested manually growng the DB, but can you expalin how I would do
this.[vbcol=seagreen]
> Cheers
> Coburndavis
>
> "Andrew J. Kelly" wrote:
for[vbcol=seagreen]
try[vbcol=seagreen]
dependant[vbcol=seagreen]
play[vbcol=seagreen]
will[vbcol=seagreen]
no[vbcol=seagreen]
fit[vbcol=seagreen]
much[vbcol=seagreen]
were[vbcol=seagreen]
it[vbcol=seagreen]
initiated[vbcol=seagreen]
Manually[vbcol=seagreen]
rows[vbcol=seagreen]
for[vbcol=seagreen]
defined[vbcol=seagreen]
|||For what it's worth, using the FAT file system caps file sizes to a few GB
(3 or 4GB, I forget
the exact size). Worth checking out?
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:u7w8CaGaFHA.3488@.tk2msftngp13.phx.gbl...
> If space is NOT an issue and you are truely set to AUTOGROW, then I
suspect
> you current database size is, hmmm, about, what? 2 GB?
> If so, then you are using MSDE and just found one of the restrictions of
> that edition. The only known solution is to upgrade to a Server-Class
> edition or split your database into multiple databases...hey, just like
you
> would do with MS Access. Sound familiar? That's why MSDE stands for MS
> Desktop Edition, it is a personal replacement or alternative to MS Access,
> but not for Server-class, production, Client/Server or n-Tier solutions,
> only Standard and Enterprise Editions are, and now, the new Workgroup
> Edition-although, WE has its own restrictions.
> Now, the Web Host sounds suspicious. I don't believe anyone would attempt
> to run MSDE as a hosted edition. Are you on a dedicated server or are you
> sharing? Do you know if the hosted database is set to AUTOGROW or not?
Do
> you know how much free space is on the drives for the hosted server? Do
you
> know if the ISP has quotas turned on for you data file folders-usually,
you
> would get a different error message if this were the case, but I would
check
> anyway?
> Sincerely,
>
> Anthony Thomas
>
> --
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in[vbcol=seagreen]
> message news:ObeUpDUYFHA.3320@.TK2MSFTNGP12.phx.gbl...
> this.
> ALTER DATABASE dbname MODIFY FILE ( NAME = logical_file_name, SIZE =
> <desired size>)
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "COBURNDAVIS" <COBURNDAVIS@.discussions.microsoft.com> wrote in message
> news:AF941E5B-58BF-42F5-8100-B7B5517CCAD4@.microsoft.com...
> though
> Autogrow.
> this.
on[vbcol=seagreen]
> for
model[vbcol=seagreen]
> try
> dependant
> play
> will
tables -[vbcol=seagreen]
> no
fine[vbcol=seagreen]
just[vbcol=seagreen]
all[vbcol=seagreen]
> fit
> much
> were
time[vbcol=seagreen]
> it
> initiated
put[vbcol=seagreen]
free
> Manually
> rows
> for
> defined
>
|||> If so, then you are using MSDE and just found one of the restrictions of
> that edition.
If my memory serves me, you get some other error message of you reach max data size on MSDE. Not
sure, though...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message news:u7w8CaGaFHA.3488@.tk2msftngp13.phx.gbl...
> If space is NOT an issue and you are truely set to AUTOGROW, then I suspect
> you current database size is, hmmm, about, what? 2 GB?
> If so, then you are using MSDE and just found one of the restrictions of
> that edition. The only known solution is to upgrade to a Server-Class
> edition or split your database into multiple databases...hey, just like you
> would do with MS Access. Sound familiar? That's why MSDE stands for MS
> Desktop Edition, it is a personal replacement or alternative to MS Access,
> but not for Server-class, production, Client/Server or n-Tier solutions,
> only Standard and Enterprise Editions are, and now, the new Workgroup
> Edition-although, WE has its own restrictions.
> Now, the Web Host sounds suspicious. I don't believe anyone would attempt
> to run MSDE as a hosted edition. Are you on a dedicated server or are you
> sharing? Do you know if the hosted database is set to AUTOGROW or not? Do
> you know how much free space is on the drives for the hosted server? Do you
> know if the ISP has quotas turned on for you data file folders-usually, you
> would get a different error message if this were the case, but I would check
> anyway?
> Sincerely,
>
> Anthony Thomas
>
> --
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
> message news:ObeUpDUYFHA.3320@.TK2MSFTNGP12.phx.gbl...
> this.
> ALTER DATABASE dbname MODIFY FILE ( NAME = logical_file_name, SIZE =
> <desired size>)
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "COBURNDAVIS" <COBURNDAVIS@.discussions.microsoft.com> wrote in message
> news:AF941E5B-58BF-42F5-8100-B7B5517CCAD4@.microsoft.com...
> though
> Autogrow.
> this.
> for
> try
> dependant
> play
> will
> no
> fit
> much
> were
> it
> initiated
> Manually
> rows
> for
> defined
>
|||Nope, that's the exact error message. Unfortunately though, MSDE maximum
size is not necessarily the only possible cause. You do get a different
error message if you max out your 8 concurrent connections, but this is the
message for the Database Size restriciton. Only because I wrestled with a
System Admin for about an hour one time before he brought that little tidbit
of information to my attention...then all became clear.
That and the fact that we are talking about an ISP system would beg this
question, but I would certainly ask or at least query the system to find
out.
Sincerely,
Anthony Thomas

"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:%23uL2kFcaFHA.720@.TK2MSFTNGP15.phx.gbl...
> If so, then you are using MSDE and just found one of the restrictions of
> that edition.
If my memory serves me, you get some other error message of you reach max
data size on MSDE. Not
sure, though...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:u7w8CaGaFHA.3488@.tk2msftngp13.phx.gbl...
> If space is NOT an issue and you are truely set to AUTOGROW, then I
suspect
> you current database size is, hmmm, about, what? 2 GB?
> If so, then you are using MSDE and just found one of the restrictions of
> that edition. The only known solution is to upgrade to a Server-Class
> edition or split your database into multiple databases...hey, just like
you
> would do with MS Access. Sound familiar? That's why MSDE stands for MS
> Desktop Edition, it is a personal replacement or alternative to MS Access,
> but not for Server-class, production, Client/Server or n-Tier solutions,
> only Standard and Enterprise Editions are, and now, the new Workgroup
> Edition-although, WE has its own restrictions.
> Now, the Web Host sounds suspicious. I don't believe anyone would attempt
> to run MSDE as a hosted edition. Are you on a dedicated server or are you
> sharing? Do you know if the hosted database is set to AUTOGROW or not?
Do
> you know how much free space is on the drives for the hosted server? Do
you
> know if the ISP has quotas turned on for you data file folders-usually,
you
> would get a different error message if this were the case, but I would
check
> anyway?
> Sincerely,
>
> Anthony Thomas
>
> --
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote
in[vbcol=seagreen]
> message news:ObeUpDUYFHA.3320@.TK2MSFTNGP12.phx.gbl...
> this.
> ALTER DATABASE dbname MODIFY FILE ( NAME = logical_file_name, SIZE =
> <desired size>)
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "COBURNDAVIS" <COBURNDAVIS@.discussions.microsoft.com> wrote in message
> news:AF941E5B-58BF-42F5-8100-B7B5517CCAD4@.microsoft.com...
> though
> Autogrow.
> this.
> for
model[vbcol=seagreen]
> try
> dependant
> play
> will
tables -[vbcol=seagreen]
> no
fine[vbcol=seagreen]
> fit
> much
> were
> it
> initiated
put
> Manually
> rows
> for
> defined
>