We're currently running a POC with Snowflake and want to integrate it with our existing on premises SQL Server 2019 data warehouse. I've been playing with the standard ODBC driver provided by snowflake, and can get Polybase to connect and talk to tables in our snowflake instance, however I can't get it to play nice with date based columns:
Msg 105083, Level 16, State 1, Line 1
105083;The following columns in the user defined schema are incompatible with the external table schema for table 'DateTest': 'DATE1' failed to be reflected with the error: 'The detected ODBC SQL_TYPE 11 is not supported for external generic tables.'. Could not reflect the following detected external table columns: 'DATE1' failed to be reflected with the error: 'The detected ODBC SQL_TYPE 11 is not supported for external generic tables.', 'DATE2' failed to be reflected with the error: 'The detected ODBC SQL_TYPE SqlDateTime is not supported for external generic tables.', 'DATE3' failed to be reflected with the error: 'The detected ODBC SQL_TYPE SqlDateTime is not supported for external generic tables.'.
Completion time: 2021-03-02T14:11:52.7221079+10:00
I've attempted to follow the ODBC parameter options mentioned here: https://docs.snowflake.com/en/user-guide/odbc-parameters.html
From what I read, I would've thought this parameter would've solved it, but no luck at least from I can see: odbc_use_standard_timestamp_columnsize
I'm all out of ideas on what/if anything that I can do here. I have found an ODBC driver provided by CDATA that seems to work, but I suspect it is going to cost a lot of money, so would prefer to see if the standard snowflake ODBC driver will work first.
Related
Since last upgrade of ms-access while using pass through query results in this error:
sql server query on odbc get error - [Microsoft][ODBC Driver Manager]
Invalid cursor state 0
(Office Access 365 version 1911, while return records on query is true...)
After downgrade Access version- the problem solved...
https://learn.microsoft.com/en-us/officeupdates/update-history-office365-proplus-by-date
Any one got over solution?
This answer
This is a bug introduced in Office Version 1912, which is an Insiders
build, so most users, on Monthly Channel (still on Version 1911),
won't see this.
This will be fixed in the next release of Version 1912, which might be
a re-release for Insiders, or it may not be until it becomes the next
Monthly Channel build in a few weeks.
In the meantime, the easiest workaround is likely to switch to the
Monthly Channel build until the fix is released.
Shane Groff
Access Engineering
I am having a problem with connecting to data in SQL database.
I am not sure if I don't have the certain driver or if the code I am using is incorrect. Could someone please help guide me in the right direction?
Below is the product license that I have after running Proc Setinit
Operating System: WX64_WKS.
Product expiration dates:
---Base SAS Software
14FEB2018
---SAS/STAT
14FEB2018
---SAS/GRAPH
14FEB2018
---SAS/Secure 168-bit
14FEB2018
---SAS/Secure Windows
14FEB2018
---SAS Enterprise Guide
14FEB2018
---SAS/ACCESS Interface to PC Files
14FEB2018
---SAS/ACCESS Interface to Microsoft SQL Server
31DEC2017
---SAS Workspace Server for Local Access
14FEB2018
---SAS/ACCESS to Amazon Redshift
31DEC2017
---High Performance Suite
14FEB2018
Below is product installed after I ran Proc Product_Status
16 proc Product_Status ; run;
For Base SAS Software ...
Custom version information: 9.4_M5
Image version information: 9.04.01M5P090617
For SAS/STAT ...
Custom version information: 14.3
For SAS/GRAPH ...
Custom version information: 9.4_M5
For SAS/ACCESS to Amazon Redshift ...
Custom version information: 9.42
For High Performance Suite ...
Custom version information: 2.2_M6
For SAS/ACCESS Interface to PC Files ...
Custom version information: 9.4_M5
NOTE: PROCEDURE PRODUCT_STATUS used (Total process time):
real time 0.24 seconds
It seems like sas access to SQL server is not installed right?
I am also trying these codes to connect and all got the error. Which direction of code should I be using? ODBC or sqlsvr?
I tried sqlsvr and got this error message
Code:
LIBNAME database1 sqlsvr user=datareader password=myspassword DATAsrc=clientA;
Error:
LIBNAME database1 sqlsvr user=datareader password=XXXXXXX
DATAsrc=clientA;
ERROR: CLI error trying to establish connection: [Microsoft][ODBC
Driver Manager] Data source name not found and no default driver
specified ERROR: Error in the LIBNAME statement.
When I tried ODBC route, I got this message
Code:
LIBNAME database1 ODBC DSN=clientA User=datareader Password=myspassword ;
Error:
LIBNAME database1 ODBC DSN=clientA User=datareader Password=XXXXXXX;
ERROR: The ODBC engine cannot be found. ERROR: Error in the LIBNAME
statement.
Could someone please point me in the right direction? Should DSN be the name of the database of each client as "ClientA" etc or should it be the name of the server?
Thank you so much!
The SQLSRV library engine DATASRC= option should specify an entry shown in the "ODBC Data Source Administrator (64-bit)" application. You can add an entry, set (configure) the connection parameters and test the connection. Suppose you name your new DSN Sales History, the libname might be
libname OldSales sqlsrv datasrc="Sales History" user=... pass=...;
For the case of wanting to specify the server name, schema, port, connection persistence, etcetera directly in your SAS code you would use the NOPROMPT= option. The option value will be a semi-colon separated list of name=value pairs:
libname OldSales sqlsrv user=... pass=... noprompt="Server=<url or hostname><\instance-name-if-other-than-default>,<port-number-if-other-than-default>;Initial Catalog=<database-to-use-if-other-than-default>;..other connection parameters..";
Microsoft documentation "Using Connection String Keywords with SQL Server Native Client" is a great reference. Another good resource for examples is connectionstrings website. A NOPROMPT= value that seems correct, yet is not to working, may have or require unusual spacing or quoting.
For a small group of coders in a static data hosting environment the NOPROMPT= method will probably be OK and require no extra support (other than access) in a large organization. If the data hosting migrates or changes your SAS code will have to be changed.
In a larger context, especially in a SAS Server environment, you are best off having your IT support to create the DSNs that your SAS sessions will need. The DSNs will be the single gateway that all programs and users will use and coders and analysts will not have to get bogged down in the connection details.
I’m trying to query our database in F# but I’m having a lot of errors when I get the data context.
Here is my connection command:
#r "System.Data.dll"
#r "FSharp.Data.TypeProviders.dll"
#r "System.Data.Linq.dll"
open System
open System.Data
open System.Data.Linq
open Microsoft.FSharp.Data.TypeProviders
open Microsoft.FSharp.Linq
type dbSchema = SqlDataConnection<"Data Source=OCPM;Initial Catalog=Nautilus;Integrated Security=SSPI;">
let db = dbSchema.GetDataContext()
147 errors in total are returned after this simple script, I won’t list them all but here are a couple of examples:
Script1.fsx(11,17): error FS3033: The type provider
'Microsoft.FSharp.Data.TypeProviders.DesignTime.DataProviders'
reported an error: Error reading schema. Warning : SQM1025: Unable to
extract stored procedure 'utvf_VehiclesSummaryUDT' from SqlServer because parameter 'incident' is the unsupported DbType 'Structured'.
Script1.fsx(11,17): error FS3033: The type provider
'Microsoft.FSharp.Data.TypeProviders.DesignTime.DataProviders'
reported an error: Error reading schema. Warning : SQM1014: Unable to
extract stored procedure 'asynch.usp_LBNGBasket' from SqlServer.
Invalid object name '#updatedPriceTab'.
I believe this is due to the complexity of the objects and structures used in our DB. The first error is due to a User-Defined Table Types called udt_IncidentExposure in the function utvf_VehiclesSummaryUDT. The second is because the temporary table #updatedPriceTab is called in asynch.usp_LBNGBasket but created in another stored procedures.
I’m surprised of the limited compatibility between F# and SQL Server on complex structures. Is there any other way to connect to SQL server in F#? All I need is doing very simples SQL queries.
Additional information: SQL Server version in use is 10.50.4270
You are out of luck with using production-quality SqlClient type provider because it requires at least SQL2012 to operate.
You may try SQL Type Provider, although I do not have any experience using it in production scenarios.
Also you may try using SqlEntityConnection type provider that sometimes does better job, than SqlDataConnection type provider that you've tried.
And finally, as the last resort, nothing prevents you from accessing SQL from F# through plain ADO.NET.
You can try other F# type providers from here:
http://fsharp.org/guides/data-access/#sql-data-access
The best one (IMO) for MS SQL Server is FSharp.Data.SqlClient but I believe it supports only version 2012 and up.
I'm using pdo through freetds driver to connect to Mssql database and I'd like to output detailed sql errors against the generic one.
E.g. I got this generic error from PDO
SQLSTATE[HY000]: General error: 547 General SQL Server error: Check messages from the SQL Server [547] (severity 16) [(null)]
But SQL client gives me more details, and I'd like to get them in php. E.g. in the same case:
The DELETE statement conflicted with the REFERENCE constraint "FKORDINICLIENTI". The conflict occurred in database "dbo.Ordini", column 'IDCliente' of database "dbName".
I've already read this old note PHP / PDO / MSSQL how to get error informations?
and I'd prefer to avoid an additional query.
Thanks.
I think code doesn't matter, I know what's wrong in sql, just wanted to access the second code block from php.
I solved using odbc driver instead of freetds.
I am currently running a third-party software suite, which uses SQL Server as its database. I have a second instance of SQL Server running in a different location, and some apps that I am building in that instance SQL Server needs to access some data in the third-party software. So, I created an ODBC connection between the boxes, and set up the third-party SQL server as a linked server on my version of SQL Server. As a test, I ran something like the following statement from my SQL server, accessing one of the third-party's tables:
SELECT * FROM LinkedServerName.SchemaName.dbo.TableName
To which I recieved this error:
OLE DB error trace [Non-interface error: Column 'TableRowVersion' (compile-time
ordinal 4) of object '"SchemaName"."dbo"."TableName"' was reported to have a
DBCOLUMNFLAGS_ISROWVER of 0 at compile time and 512 at run time].
Msg 7356, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' supplied inconsistent metadata for a column. Metadata
information was changed at execution time.
This error is the same for any other table I try to access. What does this error mean, and is there a way around it?
I've had this happen a few times. The one workaround I found was to use OPENQUERY.
SELECT * FROM OPENQUERY(LinkedServerName, 'SELECT * FROM DBName.Schema.Table')
Also, the select you posted above has an incorrect 4 part name (could just be a typo but I wasn't sure). It should be LinkedServerName.DBName.SchemaName.TableName
Server: Msg 7356, Level 16, State 1, Line 1
OLE DB provider 'MSDASQL' supplied inconsistent metadata for a column.
Metadata information was changed at execution time.
If you use a four-part name syntax to query the data from the linked server database, you may receive this error message. To work around this problem, you can use the OPENQUERY syntax to query the data from the linked server database. You can turn on trace flag 7300 to receive more detailed information about this error message. To turn on trace flag 7300, run the following Transact-SQL statement:
DBCC TRACEON(7300)
I solved this with these steps:
1) Step 1:
• In SQL Server Management Studio open Linked Servers and then 'New Linked Server'.
• Inside of appeared wizard – Select the General tab.
• Specify alias name in "Linked server" field.
• Select SQL Native Client as provider.
• Add sql_server in "Product Name" field (that's the magic).
• In Data Source – specify name of the host to be used as linked server.
2) Step 2:
• In Security tab – specify proper security options (e.g. security context)
3) Step 3:
• In Server Options tab – put "Data Access", RPC, "Rpc Out" and "Use Remote Collation" to be true.
4) Step 4:
• Enjoy.
http://alexpinsker.blogspot.com.br/2007/08/how-to-give-alias-to-sql-linked-server.html