I have to work on a project connecting to a SQL Server DB, while working with PHP and a Laravel framework.
My issue is with the data types and where I would be able to change them into fully functional and more 'conventional' SQL data types. So let's take NVARCHAR for example, would I be able to change into a normal VARCHAR?
The types I have are:
NCHAR
NVARCHAR
GEOGRAPHY
I've read over here that :
Laravel uses db-library (if it's available) to connect to Sql Server
which cannot receive unicode data from MSSQL. (1,2)
Is there anyone in the crowd that work with Laravel and preformed such a task?
You can use following convention I found from MSSQL data types to MYSQL data types
NCHAR => CHAR/LONGTEXT
NVARCHAR => VARCHAR/MEDIUMTEXT/LONGTEXT
Still couldn't find a solution for GEOGRAPHY type. I'll keep you posted.
Found this on GEOGRAPHY but it clearly doesn't mention a counterpart to it.
Related
I was trying to change the data type into XML in order to split one column into multiple columns. However, when I ran the syntax below, an error: cannot find data type XML was showed. I searched some of the answers online. It seems Azure is supported for XML. Is there a way to solve it?
cast('<m>'+replace(Employee_Name,#delimiter,'</m><m>')+'</m>' as XML)
Besides, I found that IDENTITY(1,1) is not supported either.
With SQL-Server 2016 there is native support for this: STRING_SPLIT()-function. But - according to the linked doumentation - this seems not to be offered for Azure Data Warehouse...
The string splitting via XML needs the XML-DataType, since you will need .nodes() and .value() to retrieve the values. According to this documentation this is supported with Azure Database, don't know of restriction with the Data Warehouse version...
There are many examples for string splitting functions using loops or recursive CTEs. This article compares some of them...
This error occurs when you try to run the query casting to XML while logged into a Microsoft Azure SQL Data Warehouse. Azure SQL Data Warehouse does not support the XML datatype. You can confirm your version with the following sql:
select ##version
https://learn.microsoft.com/en-us/azure/sql-data-warehouse/sql-data-warehouse-tables-data-types
I've been trying with no success to run evolutions + slick to generate schema for a MSQLServer database.
I am using Play 2.3.x, scala 2.11.6, slick, and SQLServer 2014.
I could make it connect as well, but the script which is generated contains lots of "errors" relates to data types, like the use of BOOLEAN and TIMESTAMP which are types that SQLServer does not use.
The script should use the types BIT instead of BOOLEAN, DATETIME instead of TIMESTAMP, and UNIQUEIDENTIFIER instead of UUID.
Does anyone know a workaround for that?
These datatypes and all specific to database so there is no workaround here.
You have change the data types based on the selected database otherwise you will get the same error in another database as well.
I need to upload some data from an Oracle table to a SQL Server table. The data will be uploaded to the SQL server using a Java processing utilising JDBC facilities.
Is there any benefit in creating the SQL server columns using nvarchar instead of varchar?
Google suggests that nvarchar is used when UNICODE characters are involved but i am wondering does nvarchar provide any benefit in this situation? (i.e. when the source data of the SQL Server table comes from an Oracle database running a Unix environment?)
Thanks in advance
As you have found out, nvarchar stores unicode characters - the same as nvarchar2 within Oracle. It comes down to whether your source data is unicode - or whether you anticipate having to store unicode values in future (e.g. internationalized software)
I am using Access 2003 as a front end UI for a SQL Server 2008 database. In looking at my SQL Server database design I am wondering if nvarchar was the right choice to use over varchar. I chose nvarchar because I thought it would be useful in case any characters represented by unicode needed to be entered. However, I didn't think about any possible issues with Access 2003 using the uni-code datatype. Are there any issues with Access 2003 working with unicode datatypes within SQL Server (i.e. nvarchar)? Thank you.
You can go ahead and use nvarchar, if that's the correct datatype for the job. Access supports Unicode data, both with it's own tables and with external (linked) tables and direct queries.
I am using Castle ActiveRecord as my ORM. When I try to store unicode strings, I get question marks instead.
Saving unicode strings worked perfectly when I was using mysql, but when I recently switch to SQL Server it broke. How should I go about fixing this?
You're most likely using the incorrect SQL Server data type. varchar is meant for a plain-old character while nvarchar is meant for Unicode characters. The same applies for char & nchar and text and ntext.
MSDN for SQL Server data type
MSDN for SQL Server Unicode data