In SQL server 2008 Management studio I can do this
Use [C:\test\somedb...]
When I use Delphi 2009 with the same command, using ADO, the [] seems to be interpreted as a parameter and the command fails with parameter improperly defined error. There is no parameter - I just need to use the [] because of the \ in the file name. Double quotes don't work either in Delphi / ADO or Management Studio.
Thanks in advance...
With ADO, you don't typically USE in the SQL. You specify the database and the other information (driver, etc.) in the ConnectionString. It works in SSMS because that's not using ADO; SSMS uses the SQL Server client directly (which has different requirements than ADO).
You can find connection string information for your specific SQL Server version here.
Related
To monitor SQL Server jobs in a VBA app, I run the sp_get_composite_job_info stored procedure from the msdb database using ADO. I check the current_execution_step field once I have the results in a ADODB.Recordset. This has worked fine with SQL Server 2012 for years.
We just migrated to SQL Server 2019 and now the same code which still works on SQL Server 2012 is returning an unreadable value for the current_execution_step field.
Instead of "4 (Step Name)", I get a bunch of rectangles and squares.
If I run the same call to sp_get_composite_job_info in SSMS, I can read the current_execution_step field just fine on both servers. It's only when I try to read that field in VBA/ADO that it's gibberish.
What's worse, I can read other fields from that same recordset just fine. It's only this one field (which just happens to be the only field I need to read) that is unreadable.
The driver I'm using in VBA is ODBC Driver 17 for SQL Server. But again, I use the same driver for both servers, and only 2019 has this issue.
What could be causing this?
The SQL Server 2012 version of sp_get_composite_job_info (undocumented as #RBarryYoung mentioned) returns current_execution_step as nvarchar(128) whereas SQL Server 2019 returns nvarchar(MAX).
ADO is unaware of SQL Server datatypes introduced after SQL Server 2000. Try installing the latest MSOLEDBSQL OLE DB driver (ADO is natively OLE DB) and specifying the DataTypeCompatibility=80 in the connection string.
Fortunately, the answer was as simple as going back to OLE and switching the Provider to SQLNCLI11 instead of SQLOLEDB. Since SQLNCLI11 is omnipresent, I don't have to hunt down all of the machines that might use these apps and install MSOLEDBSQL on them.
There is some kind of pre-processment of the SQL text on FireDAC queries that truncates their string literals containing ! characters.
It's very easy to replicate:
Place a TFDConnection, a TFDQuery connected to the connection, a TDatasource connected to the query and a TDBEdit connected to the datasource.
After setting my server configuration on the TFDConnection, if I try this SQL on the TFDQuery : Select 'Hel!o World' as column, I would only see He on the TDBEdit instead of Hel!o World.
It's a problem of FireDAC because the same query runs fine directly on SQL Server Management Studio.
Is there a way to fix o disable this pre-processment of FireDAC ?.
It's Delphi 10.4 and SQL Server 2017 accessed by SQL Server Native Client (I have also tried the same query on Delphi 10.3 and returns the same error).
Thank you.
I am trying to create a linked server from SQL Server 2008 R2 to an SAP IQ database, which has the UTF-8 Charset.
I am unable to get the correct characterset viewable on queries using this linked server.
I have tried everything, using native OLE DB provider of SAP IQ, using ODBC connectivity, playing with different connection strings, but my major concern is that it's impossible because SQL Server does not support UTF-8.
Correct characters when viewing in Interactive SQL:
Messed up characters in SQL Management Studio:
Any thoughts?
Finally solved it, after a few hours of debugging. :)
You have to use an ODBC connection, with the CharSet parameter set to 'windows-1252'. Then it works perfectly.
I have a SQL Server 2012 database with an Access 2007 front-end. My problem is that Access does not recognise SQL Server's dates as they are in a different format.
SQL Server-s format is YYYY-MM-DD
Access' format is DD-MM-YYYY
When the date is displayed in a text-box, it is displayed as a string (without the little calendar icon next to it).
Is there anyway I can configure my Access front-end so that it recognises SQL Server's dates?
I used Microsoft SQL Server Migration Assistant for Access to migrate the data into SQL Server
As this DB is in development I have the SQL Server on my local machine in C drive (no virtual drives)
From my research I have found this answer:
The problem the user has encountered is with a Driver. Microsoft has a new DLL that must be put on a client
workstation (or server in the case of Citrix). Once that is done, all the dates in MS Access will work
properly. My lastest experience with Access 2010 was exactly the same as Access 2003.
It required a DLL. From there, investigate using a DNS-Less connection string
Where would I find this DDL driver and how would I install it.
Thanks
Maggs
I found that SSMA for some reason converted all the datetimes to datetime2. I went into SQL Server Management Studio and changed them to datetimes and it fixed the issue. You could also check the field mapping in SSMA and adjust it before migrating.
(I have the exact same environment - SQL Server 2012 and Access 2007, using SSMA.)
I am using SQL Server 2012 on my local PC (Vista) and have an Access 2010 frontend with ~75 linked tables.
The table in SQL Server has a column named 'EnteredDate' that is defined as 'datetime'.
In Access the 'EnteredDate'column is defined as 'Date/Time'.
In Access, I just ran the following query with proper results:
SELECT DataError.Description, DataError.EnteredDate
FROM DataError
WHERE (((DataError.EnteredDate) Between #1/1/2010# And #1/31/2010#));
I am interested in using some kind of a command-line utility for SQL Server similar to Oracle's SQL*Plus. SQL Server seems to have several options: osql, isql, and sqlcmd. However, I am not quite certain which one to use.
Do they all essentially do the same thing? Are there any situations where it is preferable to use one over the others?
Use sqlcmd-- it's the most fully featured product.
sqlcmd: The newest, fanciest command-line interface to SQL Server.
isql : The older, DB-Library (native SQL Server protocol) way of command-line communication with SQL Server.
osql : The older, ODBC-based way of command-line communication with SQL Server.
EDIT: Times have changed since I replied on this a couple of years ago. Nowadays, you can also use the invoke-sqlcmd cmdlet in PowerShell. If you're used to PowerShell or plan to do any scripting of any sophistication, use this instead.
I'm not sure what the scope of your question is, but I believe :
isql used DB-Library to communicate to the server and is no longer included after SQL2000
osql used ODBC to communicate to the server and will no longer included after SQL2005
sqlcmd used OLE DB to communicate to the server and is currently the recommended command line tool.
Its always better to use SQLCMD instead of OSQL or ISQL if you have SQL SERVER 2005, otherwise use OSQL instead of ISQL.
Microsoft has announced before that ISQL was on its way out. Sure enough, ISQL is not included in SQL Server 2005 RTM. OSQL eventually will be phased out also, although it is still included in SQL Server 2005 binary install. With the historical SQL Server release cycle in mind, maybe OSQL will bid us adieu in 2010.
SQLCMD has many advantages as below:
1) Performance wise
2) SQLCMD supports parameterized variables
3) SQLCMD support Customized editor
4) :XML [ONOFF]
5) :Error STDERRSTDOUT
6) :Perftrace STDERRSTDOUT
7) Remote Dedicated Admin Connection (DAC)
There is a free tool "SQLSPlus" (on http://www.memfix.com ) which is exactly like Oracle SQLPlus for SQL Server. Works with all SQL Server versions.
Very flexible with data formatting (set lines size, pagesize, etc), variables (var, &, &&), spool, HTML output, etc - lots of added functionality comparing to isql, osql or sqlcmd