We have been using SQL Server on Microsoft Windows Server 2003 SP2, and are now attempting to transfer across to a new server, running 2008 R2. One of our clients has a seperate jobs database which creates text files that are updated via FTP to a folder on our server 3 times daily, to then be imported into a corresponding series of tables in our database. Here is the old code for the import:
Delete
From Client.dbo.jobs
Go
BULK INSERT CarltonRR.dbo.jobs
FROM 'D:\folder\clientDatabaseUpload\jobs.txt'
WITH
(
DATAFILETYPE='char',
CODEPAGE = '65001',
FIELDTERMINATOR = '|',
ROWTERMINATOR = '\|\n'
)
Go
After the initial errors, and subsequent searching, I removed the 'CODEPAGE = '65001', line because of the issues mentioned in this documentation, that 2008 R2 does not support UTF-8, however the database would automatically convert to UTF-16. This resulted in problems displaying some characters (£ for example) which the old system handles fine. The Data Type for the field(s) that are not displaying properly is varchar(50)
Is there a change that needs to be made to the SQL queries from 2003 to 2008 R2 that would allow the special characters in the .txt files to be displayed in the database?
Edit: The Data Type for the field(s) in question is nvarchar(50), not varchar(50)
Edit 2: If it helps, the listed sign in replacement of the ' £ ' sign is ' ┬ú '
Related
I have a local data frame of more than 4000 rows and around 10 columns. Currently using dbWriteTable function to write table into SQL server using R. But it is dead slow (takes more than 30 mins)
Is there any alternate approach for this using which I can do this faster?
Consider exporting the dataframe to csv and run SQL Server's BULK INSERT:
BULK INSERT myNewTable
FROM 'C:\Path\To\File.csv'
WITH
(
FORMAT = 'CSV',
FIRSTROW = 2,
FIELDTERMINATOR = ',',
ROWTERMINATOR = '\n',
TABLOCK
)
Alternatively, save the csv into Excel format (.xlsx) or directly from R to Excel format and run a distributed query in a make-table action:
-- Adjust path and sheet name
SELECT *
INTO myNewTable
FROM OPENDATASOURCE('Microsoft.ACE.OLEDB.12.0',
'Data Source=C:\Path\To\File.xlsx;Extended Properties=Excel 12.0')...SheetName$
SELECT *
INTO myNewTable
FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0',
'Data Source=C:\Path\To\File.xlsx;Extended Properties=Excel 12.0', SheetName$)
Notes
Bulk operations must be granted to user calling the action which is a server-level right and not database-level. Consequently, you may not be able to run command through R but in SSMS console.
Ad Hoc Distributed queries must be enabled on database to connect to remote data sources that use OLE DB.
Distributed queries assume you have SQL Server and MS Office in same bit-architecture: both at 64-bit installs with Access engine installed. If not, free MS 2007/2010/2013/2016 download are available. See 2016. If SQL Server is on 32-bit, use older Microsoft.JET.OLEDB.4.0 and save Excel file in older .xls format with properties as Excel 8.0.
I have a table, which I have clicked Edit top 200 rows, as I wish to flip a cell in one of my columns which is smallint from a 0 to a 1. Every time I change the cell's data from a 0 to a 1 it is automatically changed back to a 0.
It seems that all of my columns are immutable in this way, what am I missing so that I can edit data in my sql database table manually for testing? I am using SQL Server Management Studio 17.
When using Microsoft SQL Server Migration Assistant which converts a MySQL database to an MSSQL or Azure Sql database, triggers are generated for you during the migration and added to your SQL tables.
In my case, these were stopping me from updating and inserting to my table, so I deleted them.
We have a web application which from the UI is passing a value say 50.00 but when it is stored in the database it is stored as 50000. Most of our installations are for English OS (windows 7) but this problem is on a dutch installation.
Is there a way I can tweak SQL server so that it saves the value at 50 and not 50000 without changing any code? The field in the database is an integer.
The customer has SQL server 2008 express.
My personal computer is running Windows 7 (language turkish) and I installed SQL Server 2008. When I create a new database, the database language is Turkish_CI_AS
And I have a server with Windows Server 2003 (language english) and installed SQL Server 2008 on that server. I set the Regional and Language Options as Turkish. I am creating a database and selecting collation Turkish_CI_AS
But when I insert a row into a table on the server, an error occurrs:
The date format is invalid
You should always use unambigious formats like YYYYMMDD or YYYYMMDD HH:MM:SS so that no matter what setting the server/database is it will be added correctly. Read this for a better understanding http://beyondrelational.com/modules/2/blogs/70/posts/10898/understanding-datetime-column-part-ii.aspx
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.