Versions in use:
SQL Server 2016
Azure Data Studio 1.36.2
SQL Server Schema Compare 1.13.1
Problem: there is something wrong with my Azure Data Studio apply schema to SQL Server 2016.
It say I'm not the login manager but there is no login manager role in SQL Server.
And it has worked before updating Azure Data Studio to v1.36.X
https://imgur.com/a/JFWFOtn
Finally, I found the problem
Misused sqllinlinetablevaluedfunction and sqlmultistatementtablevaluedfunction
In my project There are many function use sqllinlinetablevaluedfunction instead of sqlmultistatementtablevaluedfunction but It's should be used sqlmultistatementtablevaluedfunction
so I change to Correct Type then It's worked. The error never show
Using a create table syntax as follows within a Visual Studio 2019 SQL Server Database Project:
CREATE TABLE [MyTable]
(
-- ...
) WITH (DATA_COMPRESSION = PAGE)
I receive the following build error:
SQL70015: Keyword or statement option 'DATA_COMPRESSION' is not supported for the targeted platform.
However, the DATA_COMPRESSION option is supported by Azure SQL Database as indicated by the documentation ("Compression is available in Azure SQL Database") and by the fact that I can manually execute this statement against an Azure SQL Database successfully.
I have configured the target platform to be "Microsoft Azure SQL Database" in the 'Project Settings' tab of the database project's properties page.
The false positive is preventing me from building (and thus deploying) the database project.
I had the same problem, the solution was:
1ª - {your project} >> properties >> change the "target plataform" to some thing else, save and build.
2ª - Change back to "Microsoft Azure SQL Database", save and build.
These steps will update the parameter of the project to newest version, in my case was:
From: Microsoft.Data.Tools.Schema.Sql.SqlAzureDatabaseSchemaProvider
To: Microsoft.Data.Tools.Schema.Sql.SqlAzureV12DatabaseSchemaProvider
Error at first step: One or more unsupported elements were found in the schema used as part of a data package. Error SQL71564: The element User: (schema name) has property AuthenticationType set to a value that us not supported in Azure SQL Database v12
It seems ,you are having some users configured to use windows authentication..so try dropping those users and try exporting as bacpac again...
Instead of using SSMS export to bacpac option..You can use DACPAC (Bacpac+data)
below is the total syntax..
.\SqlPackage /Action:Extract /SourceServerName:SourceSQLServer /SourceDatabaseName:SourceDB
/TargetFile:”C:\Temp\DBMigration\SourceDB.dacpac” /p:ExtractAllTableData=true
/p:ExtractReferencedServerScopedElements=false /p:IgnoreUserLoginMappings=true
Last two parameters are optional,but changing userloginmappings property to false will help you
References:
https://blogs.msdn.microsoft.com/dfurman/2015/03/25/database-migration-to-sql-azure-using-a-bacpac-a-blocker-and-a-workaround/
How can I import a .dbf file into SQL Server using a SQL script?
Found answers from this post, but unfortunately none of them work to me :( :
Trying to Import FoxPro DBF File to SQL Server
and
How to import a DBF file in SQL Server
When I'm trying this code :
SELECT *
INTO [APP_DB]..[BILLHEAD]
FROM OPENROWSET('MSDASQL', 'Driver=Microsoft Visual FoxPro Driver; SourceDB=D:\DBF; SourceType=DBF', 'SELECT * FROM BILLHEAD')
I get this error:
OLE DB provider "MSDASQL" for linked server "(null)" returned message "[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified". Msg 7303, Level 16, State 1, Line 1 Cannot initialize the data source object of OLE DB provider "MSDASQL" for linked server "(null)".
And also, when trying this :
SELECT *
FROM openrowset('VFPOLEDB','D:\DBF\BILLHEAD.dbf';'';
'','SELECT * FROM BILLHEAD')
I get this error :
Msg 7438, Level 16, State 1, Line 1
The 32-bit OLE DB provider "VFPOLEDB" cannot be loaded in-process on a 64-bit SQL Server.
I don't want to download any third party application. That's why I'm trying all the possible solution and I need your help now guys. I'm creating a small application to import .DBF files into SQL Server.
Regards,
You are using 64-bit SQL sever, but FoxPro OLE DB driver is 32-bit. You need to consult this article which discusses how to use the 32-bit OLE DB driver with 64-bit SQL Server.
Gimo, I'm not sure this will work and I'm no MS SQL Server expert, but I've been wrestling with a similar problem lately and I have an idea. I think you may be able to get that first block of code from your question to work if you execute the following statements first:
EXEC sp_configure 'show advanced options', 1
RECONFIGURE;
GO
EXEC sp_configure 'Ad Hoc Distributed Queries', 1
RECONFIGURE;
GO
This may not work if you don't have adequate permissions (which happened in my situation), but it may be worth a shot.
Our office SQL/GIS guru, Burce, solved a similar problem I was having. I'm not sure of all the details of how he did it, so while I am reluctant to enter this as an "Answer" (it is too many characters to enter as a Comment) I'll describe what I can in case it is helpful for anyone. First be aware that he has full permissions on the SQL Server, so this solution may not be feasible for all DB users to implement. Bruce set up a Linked Server that's connected to a directory ".../DBF/" on our LAN file server. He also set up a similar Linked Server & directory for CSV files. Anyone in our office can simply copy a DBF file to this directory and then access it in SQL Server as if it were a regular table in a SQL Server database. I access this in SSMS by connecting to the Database Engine then going to Server Objects > Linked Servers > "DBF" > Catalogs > default > Tables > file name . The Properties of the Linked Server say the following:
From General tab of Properties window
From Security tab of Properties window
From Server Options tab of Properties window
Note that this may or may not be a secure configuration for all database server environments, but this is on a SQL Server that is on our internal network, only accessible within our office, with no endpoints or access outside our LAN (it's not used as a server for web, or other internet services).
I have had similar problems where stuff just wasn't working trying to move legacy tables from VFP to SQL 2008R2 and used the following procedure:
select table within VFP
copy to blahblah xl5
Step 2 results in an excel file
Use SQL 2008 R2 or higher "Import and Export Data (32 bit)" to import the excel file.
I was running Windows 7 64 bit and still had to use the 32 bit import to make it work smoothly.
This may explain why you need the 32 bit Import: https://msdn.microsoft.com/en-us/library/ms141209.aspx
Hey folks, the person I am buildling a website for decided to design their own database. They used Microsoft SQL Server Management Studio to build it and such. Now that they are done with the database they exported it to a text file (Tasks -> Generate Scripts). Now when I try to import the file into phpmyadmin I get the following error:
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '[master] GO /****** Object: Database [Butterbakers] Script Date: 02/15/201' at line 1
The database code is here: http://zamn.pastebin.com/Y3u7MpZ9
phpmyadmin is for MySQL.
Microsoft SQL Server is a different DBMS.
Large parts of the SQL Syntax is DBMS/vendor specific.
The MySQL Workbench has a feature to "Create EER Model from existing Database".
This may be a try but you need a jdbc connection to the MS SQL Server and MySQL...
Converting DDL to a different DBMS is all but easy. And if you're done this doesn't guarantee that an probably already existing application is still working with the other DBMS.
Not switching DBMS and using the free MS SQL Express could be an option.
First decide for a DBMS and restart form zero is surely the cleanest and less painful solution.
With SQL Compare (http://www.red-gate.com/products/sql-development/sql-compare/) and SQL Data Compare (http://www.red-gate.com/products/sql-development/sql-data-compare/) , you can synchronize different DB.