I have a database on SQL Server 2000. There are only two logical files in the PRIMARY file group: the data file and the log file. However, when restoring the database to SQL Server 2008 R2, there is now a new logical file named ftrow_Table1Field1 with a file name ftrow_Table1Field1{GUID}.ndf. (I've replaced the actual table, field name, and GUID for simplicity.) The path to the .ndf file is MSSQL10_50.MSSQLSERVER\MSSQL\FTData\.
I did not create this logical file, nor did I enable full-text search on the database. Field1 was originally a TEXT data type in SQL Server 2000, which I've changed via T-SQL to a VARCHAR(MAX) column. This is also not the only column I've converted from TEXT to VARCHAR(MAX).
Can anyone shed some light on what is going on here?
EDIT: I did another restore without running my massive T-SQL scripts for the next software release. Direct from the SQL Server 2000 backup, it creates this file. Looking at the Properties of the field in SSMS, it says Full Text is False. The data type is TEXT. This is not the only TEXT field in the database.
Okay. I figured it out. The SQL 2000 database thought there was a full-text index enabled on the field, but it wasn't really enabled. This carried over to SQL 2008 R2 during the restore, because R2 restored in SQL 2000 compatibility mode and preserved the presumed .NDF. I just removed that file from the file group, and it's good. Also, R2 will create full-text indexes in the .MDF itself, as opposed to creating an .NDF.
Related
I want to link a SQL Server table to a text file so that any changes made to the text file, such as creating, deleting, or updating a row, are reflected in the SQL Server table.
The best way to do this appears to be SSIS, but I know that this is only for certain versions of SQL Server. I don't appear to have one of these versions, and this is not likely to change anytime soon.
Is it possible to achieve this result without SSIS?
Update: I am working with SQL Server 2016 Express.
Example of text file:
ITEM NUMBER ;LINE ;LOCATION
1234432 ;SHIPPING ;505R13201C
I am trying to export the tables [around 40] and stored procedures [around 120+] in SQL Server 2008 R2 from dev server to prod server.
I have created a .sql file [right clicking on the database in SSMS, choosing Tasks -> Generate Scripts], but when I am trying to import the table and stored procedures into the prod server [right clicking on the database in SSMS, New Query then copying the content in] it is giving me a long list of errors
Mostly
There is already an object named 'tblMyTable' in the database
Violation of PRIMARY KEY constraint 'PK_MyTable'. Cannot insert
duplicate key in object 'dbo.tblMyTable'
Any idea what I am doing wrong or what should be done? Thanks in advance.
The problem with your current technique is that assumes your target is an empty database. So it will reinsert everything with no attempt at merging data and this is what causes your duplicate primary keys. If you use Management Studio you have to do all the merging of data yourself.
My recommendation is first to look into redgate it's not free but all the time you will save it will be worth it. You will need to use both SQL Compare and Data Compare ( http://www.red-gate.com/products/sql-development/sql-data-compare/ ).
Another alternative is to use Visual Studio 2010 premium if you have it( http://msdn.microsoft.com/en-us/library/aa833435.aspx and http://msdn.microsoft.com/en-us/library/dd193261.aspx). This gives both a data compare and a schema compare option. It is not as good as redgate but I found it works most of the time.
If you are looking for free alternatives check out this stack post https://stackoverflow.com/questions/377388/are-there-any-free-alternatives-to-red-gates-tools-like-sql-compare.
if you are importing the whole database to production you might as well do a restore with replace to the production database.
120 SPs and 20 tables seemed to be the whole database. so Restore with replace should be done.
I want to copy a SQL Server 2005 database to SQL Server 2008 but I don't want to pickup the collation from the 2005 db. I want to use the default collation in 2008.
If you backup/restore or detach/attach a database from one system to the other, you'll always have that database's collation come with it - there's no option to disable that.
So you can basically do one of two things:
use one of those methods to move the database from SQL Server 2005 to 2008, and then change the collation after you've restored/attached the database
or:
generate a ton of INSERT scripts from the old database and re-create its structure on 2008 with that server's default collation, and run those insert scripts on your new database
Try DBSourceTools.
http://dbsourcetools.codeplex.com
It will script all database objects to disk, and then through a "Target Database", re-create the database, with all objects and data.
It has been tested on SQL 2000, 2005 and 2008.
It uses BulkCopy to insert data, so can import thousands of rows of data.
I ended up using the OSQL command line utility to run the script and it worked fine.
what is mssqlsystemresource database? do we need to copy this while moving form one server to another one?
All system stored procedures, views and functions are stored in the MsSqlSystemResource database. This db is hidden, you can't see it in SSMS but lives in the data directory...should already be on your new server
run this query on the other server
select name, filename
from master..sysaltfiles
where dbid = 32767
The system resource database. You should treat it as part of your SQL Server binaries, not as part of your data. You should never copy this file, it is manipulated only by SQL Setup operations. Replacing a resource database is not supported and can render a SQL Server instance unusable.
Is there anyway to add some custom stop words to SQL Server 2005?
I found the answer:
On SQL Server 2005:
On SQL 2005 they have the concept of "noise word lists". These are essentially the same thing, but they're stored as text files in the file system. These files have names like "noiseenu.txt" (U.S. English noise word text file) and are located in a subdirectory of your SQL Server instance directory (C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\FTData\, for instance). You can edit it with any text editor and save again. I don't recall whether or not you need to bounce the service afterwards on 2005 (don't recall if the noiseword list is cached in memory, but you may as well bounce it to be sure). Then you have to rebuild your full-text indexes.
On SQL Server 2008:
You can create a custom stopword list on SQL 2008 the server will remove the stopwords at index time and when it parses your full-text search queries. All you have to do is specify that your full-text index use the custom stoplist.