I'm fairly new to SQL Server. I have done basic admin, backups etc. I have also spent 2 years doing MySQL for a software company offering software support for their MySQL bespoke program. I'm mainly a tech guy (desktop, Networking) but getting my head round this DB stuff!
I have started with a company that run SQL Server 2005 and need some stuff doing, and I am struggling with the syntax more than anything. The company have 4 SQL Servers running the same db's (program wise) for 4 differing locations.
What I am trying to do is copy the updated cost price list from table 1 to the other tables with * criteria. Basically copy table.parts from server1.parts to server2.parts * currencyconvertion field * markup (%)
That bit seems to be quite easy except I cannot get the db's to link. I enter the server name which contains - and the syntax says wrong eg uk-server1 'can't find 'uk'? Also I am unsure in the 4 part address is correct servername, dbname, schema, table?
Right ok. Previously when tried I was unable to link the two servers. I have now resolved this and the server is now linked. I have been told that maybe there is a need for [] to quote'' server name. I have tried this with no success. The problem seems to be the name of the server having a - uk-efacs. as soon as I type this and remember it is now linked the herror is can't find server efacs an uk is wrong?? It's not ready the full server name? WHY?
Figured this out by trial and error just needs [] by server name ie [uk-efacs].db.table.field. This now is ok just need to work on my syntax as the query shows errors.
Try creating a Linked Server record on the server you're running this from. In Object Explorer (in SSMS) expand Server Objects, right click Linked Servers and select new. Select SQL Server and type the name of your remote server and then try your query again. Bit puzzled as the snippet you provided
update partmaster
set partmaster.fsunit = uk-efacs.efacsdb.partmaster.fsunit * uk-efacs.efacsdb.currency.currate * 1.32
Seems to parse just fine.
Related
I was trying to pull data from Oracle to MSSqlserver database using Linked server.
select * from [LINK_NAME]..SCHEMA.TABLE;
But it was failing with the below error:
The OLE DB provider "OraOLEDB.Oracle" for linked server "LINK_NAME"
supplied inconsistent metadata for a column. The column "COLUMN_NAME"
(compile-time ordinal 6) of object ""SCHEMA"."TABLE"" was reported to
have a "LENGTH" of 100 at compile time and 200 at run time.
I also need to pass argument at run time in where condition. I found OPENQUERY as a solution but it does not support arguments at runtime.
Try using the OPENQUERY Syntax to see whether that helps..
SELECT * FROM OPENQUERY(LINK_NAME, 'SELECT * FROM db.Schema.Table')
More about OPENQUERY ...
I found solution:
The error was coming due to database column type mismatch.
ORACLE was using NVARCHAR for datatype but in case of SQLSERVER it was VARCHAR.
As NVARCHAR is double the size of VARCHAR that is why it was showing size mismatch error.
Changing the data type to same worked for me.
I have found a solution posted by this blogger. Try it out!
This tool from Sysinternals/Mark Russinovich is the best, and my only regret that day was not launching it earlier instead of scouring Google and going insane. I’ve limited Procmon to just sqlservr.exe, as it’s the SQL Service itself that loads/handles the providers and not the ssms.exe. Also of note is that the sqlservr.exe is a 64bit process while the management studio is still just 32bit. As the server service is loading the provider, and the service process is 64bit, the provider must also be available in 64 bit format.
The ODAC112021Xcopy_x64.zip was installed to C:\Oracle. What Procmon showed me however is that sqlservr is attempting to find the oci.dll in any folder but his! (It iterates through the %Path% sysvariable). When it finally gives up on find the dll, the SQL Service is in a unstable shape and the only way to stop the service was to kill it via taskmgr/procexp. Clearly I can see that the “xcopy” deployment – while not giving me any error messages – it also did not set the PATH variable! And this is what this post is really about… adding C:\Oracle and C:\Oracle\Bin to the Path variable or maybe it’s about employing investigative tools earlier in the process instead of relying on your search engine skills.
sqlservr.exe can now find the relevant DLL’s. The OCI.DLL in the root and the OraOLEDB11.DLL in the Bin subfolder. At this point I could query the database! If you did my steps as above and you still get the same error, I strongly suggest using Procmon.exe as I have instead of jumping to the next search result.
Full post is here with more details.
I've done this numerous times in the past when connecting Access queries to Excel, but now when I try and do it with a SQL Server query, I get an error message of
[Microsoft][ODBC SQL Sever Driver]Invalid parameter number
before I can even assign the parameter a value.
Once I got this error message I started to look around online for some answers, and I came across this article here. I followed these steps, which is essentially what I was doing anyway, and I still get the same error. The article is a few years old, so I'm not sure if things have changed since the release of Excel 2016 (my current version).
Is this something that cannot be done anymore without using VBA?
Just to summarize my steps, this is what I have done:
From Other Sources > From Microsoft Query
Select Database from MS Query Prompt > Click SQL button
Paste SQL > Click Return Data Button
Click Definition in Connection Properties window> Swap criteria code with ? in Command Text
Click OK
It looks as though I may have found the issue. When doing the initial connection through MS Query, you are asked to select the data source. Apparently there are two SQL Server options, one named SQL Server and another named SQL Server Native CLient 11.0. Originally I chose SQL Server, after trying numerous ways to fix this issue, I deleted the data source completely from MS Query, and started over, this time I chose SQL Server Native Client 11.0 and it worked exactly as it should. I'm not entirely sure what the difference between the two are, but it seems to have made the difference.
I had this issue as well and it turns out that because I had included square braces around the procedure I wanted to execute it seemed to think it was a parameter. e.g.
exec dbo.[myproc] #foo=?
just changing to...
exec dbo.myproc #foo=?
worked fine.
I think behind the scenes the params are being put in an array and square brackets in the sql is confusing it. Hope this helps. It may well be that sql native client 11 doesn't handle the params in the same way so you bypass this problem.
I connect from ms access (frontend) to MS SQL server (database) using ODBC and file datasource. I've created MS Access pass-trough query collecting data from SQL Server (directly calls MS SQL Server function returning table).
When I run this query in MS SQL Management console, it runs about 1s. When I run it from MS Access, using ODBC connection string, the same query runs about 5 minutes (!!). But when I clear connection string from query properties, it runs between 1 and 2 seconds (so acceptable).
Other queries and linked tables using the same connection string works correctly (so the string is rather OK)
Why the hell this one makes problem? Any idea hat to check?
I know this is an old post but... I've been googling to no avail so I wanted to put this out there...
I have a drill down SP that returns.... 200 rows max
The MS Access app uses ALL pass through queries to Azure. All work great except for this one. In SSMS it comes back almost instantly. ODBC string is the same on ALL Queries so the connection is fine.
After setting the max rows property to 1000, the form came back almost instantly. Cleared the property and it went back to slow...
This property definitely made the difference for me. Setting it to a number that is well beyond the upper limit really got this working as it should be.
hth,
..bob
I use windows authentication (trust) only.
"clear" means to remove all except "ODBC;" phrase. When I leave this notice in query properties, the Access asks for DSN, I select one, and then I got the results after 2 sek.
But When I put full connection string
ODBC;Description=My Database;DRIVER=SQL Server;SERVER=MYSERVER;APP=2007 Microsoft Office system;DATABASE=MYDB_Prod;LANGUAGE=polski;Trusted_Connection=Yes
The query I call is:
SELECT * FROM dbo.fn_MyFunction()
Function fn_MyFunction() is table valued one, returns two rows and about 50 columns ( suspected large number of column might be the issue, because other queries have less one), and it is used in access report (that's why I use pass through query - the same happens when I test with MS SQL server view linked to MS Access tablle via odbc)
The same connection string works well with other queries
It seems I found solution (or workaround rather?) I've made the tests using VPN over internet link. When I move to office - it works well and return almost immediatelly with the string I wrote above.
It is strange for me that link type have such impact: other queries works well on both (LAN an VPN over internet), but this one - only on LAN ( works over internet too but with unacceptable performance). I could understand if all works slow.. by why this one? Any idea?
I have a big deal: I have to connect (I just want to read data, not to write) to my customer's IBM AS/400 (aka iSeries, now IBM i) server...
I think I have all parameters needed (given me by the AS/400 programmer), but I can't figure out which driver I have to use, and if I have all software needed to to this!
I've installed IBM AS/400 ClientAccess 5.8 driver (with a patch for latest OS), and now I'm trying to configure a new Linked Server in my Sql Server 2008 R2 (x64) server.
First problem: Which driver should I use?
I have so many choices (but maybe none of these works!!):
IBM DB2 UDB for iSeries IBMDASQL OLE DB Provider
IBM DB2 UDB for iSeries IBMDA400 OLE DB Provider
IBM DB2 UDB for iSeries IBMDARLA OLE DB Provider
...or maybe other generic OLEDB/ODBC drivers?!
Second problem: Where should I put my parameters (in which fields I mean!)
In any case, in I choose a provider for my Linked Server, obviously I have to set my parameters...but I only have this:
Username of an ADMIN user
Password of the ADMIN user
AS/400 server IP address
The name of "main" archive, in which my data are stored (something like ACG_DATV2)
Third problem: How should I write my queries? How to reference an AS/400 "archive" and tables?
I don't know how to build my reading query: where are tables and views (?!) stored and how can I reference them?
Thank you in advance!
I think there are many ways to achieve what you want, but I'll try to explain what I would do in your case.
With that version of IBM ClientAccess (and also the patch), I should not have troubles in getting connected with a Sql Server 2008 R2 Linked Server if you use the correct data provider.
First of all, try to configure your linked server in this way:
Linked server name: what you want, it's just a custom name (example: MYAS400)
Provider: IBM DB2 UDB for iSeries IBMDASQL OLE DB Provider
Product name: not important, something like iSeries Access OLEDB Driver
Data source: AS/400 server IP address (example: 192.168.0.1)
Either if you configure the Linked Server using the wizard or by SQL code, the first time it will need to access the data of the AS/400 server, you'll be asked for credentials, with a typical iSeries window (look at my example).
Set your username (User ID) and the relative password, without regarding the case of the strings!!
As a general tip (but this is only related to my experience!), try to avoid special characters and upper/lower cases distinctions...
If you arrive here (no problems in the Linked Server creation), the Linked Server should work (so the first and the second problem are solved): let's build the first query!
Once the Linked Server is created, all you need is just to correctly reference the archive, the library and, of course, the correct table and the Linked Server (by name): with this informations, build a query like this (it's the usual T-SQL syntax):
SELECT
(Field1)
, (Field2)
, *
FROM (Linked Server Name).(Catalog Name).(Library).(TableName)
The only information you're probably missing is the "archive": you can easily find it browsing the Catalogs tree inside your new Linked Server, or just use iSeries Access Navigator tool!
So, in your case, I think the query should be (more or less):
SELECT
FILIO
, DTVLD
, DTVLA
, SEQZA
, CFIMP
, PADRE
, TPVLD
, CMVLD
, *
FROM MYAS400.S242DA0A.ACG_DATV2.ANLE200F
Note that S242DA0A is valid only in my case...
Remember also that:
AS/400 will probably ask you for credentials very often: also if you close and reopen SSMS.
Performance?...better to talk of something else :) ... extract the tables in your Sql Server tables and query them from there! Do it with a simple: SELECT (Fields) INTO myTable FROM (AS/400 table)
I've tried this process many times, I didn't have many troubles (once I get skilled about!)...but only for reading data (as you asked)! Never tried to update data!!!
GOOD LUCK!
I am using SSIS with VS2010 (shell) and databases going from SQL Server 2005 (32 bit)to SQL Server 2012 (64 bit). I am developing directly on the destination server (not optimal, but it works).
When I try to use the Transfer database task, it gives me an error message as follows:
"Error: The Execute method on the task returned error code 0x80131500 (An error occurred while transferring data. See the inner exception for details.). The Execute method must succeed, and indicate the result using an "out" parameter."
Here is the problem... how do I view an "inner exception"?? it is a GUI interface with no way to step through the code! I even tried setting up logging - it just logs the same useless error message.
Microsoft has no information for this error code in their reference docs (that I could find).
After googleing the error code, I saw others have this error code along with messages having to do with users, roles, and creating them.
I double checked that I have sysadmin rights on both servers, and
logins on both.
I tried the same Transfer Database task from each
server to itself (with changeing database name) and that worked
fine for both by themselves.
I tried both DatabaseOnline and DatabaseOffline options. (same error both ways)
I tried doing a "Transfer Logins" task before doing the transfer database task, that task worked, but not the Transfer databases task. Then it started throwing errors saying that the databases don't exist - which implies that I need to transfer logins AFTER I transfer databases.
Here are my settings:
What am I doing wrong? OR how can I get the "inner exception" message?
Also, follow my post to Microsoft's forums here:
http://social.technet.microsoft.com/Forums/en-US/sqlintegrationservices/thread/cda53c80-8da6-4ed1-898a-9f3ff8464ae2
This answer makes me sick to my stomach... I hope I save someone else this hassle. The problem was this:
First and foremost: the error message was not descriptive enough. The error should be handed to the interface.
Under "edit" on a "Transfer Database" task, the destination file paths are "auto-populated" with the file paths of the source database. They look right at first (and second, and third...) cursory glance. Upon further inspection the file paths were wrong. This makes sense if you are going from version to version - the folders are named with subtle differences according to version (MSSQL.1 vs. MSSQL11.<instanceName>).
In summary, the error was caused by the folder not existing because the path was set wrong. I imagine other low-level exceptions like this are also eaten by the interface with the same cryptic error message.
This is old but I bumped in the same cryptic message with SSMS 17.2. I tried and checked all the suggestions above to no avail.
In my case the issue was related to the TargetServerVersion property of the SSIS project in Visual studio 2017. By default this was set to SQL Server 2017, while my local server was SQL Server 2014 - once changed to the same version everything went smooth.
We ran into this where someone told us a valid date would always exist in the column in a MySQL database and we found out later that there were dates like '0000-00-00 00:00:00' and '0001-01-01 00:00:00'.
We handled it in the query that pulls in the data using a case statement to convert the bad date into a date SSIS can use :
CASE WHEN Product.PurchaseDate < '1900-01-01 00:00:00' THEN '1900-01-01 00:00:00' ELSE Product.PurchaseDate END AS PurchaseDate
Of course, you can set it to null also, your choice.
I have also had this same issue and it turned out to be an access issues. Try giving these access to the folder where the mdf and ldf files will be landing: NT Service\MSSQLSERVER, Owner Creator, System
"which implies that I need to transfer logins AFTER I transfer
databases."
not really, logins are on a server (instance) level so you can transfer logins and then the database. You would need to worry about users later, of course
a point here, I dont think SSIS would be prepared to transfer 2005 -> 2012. I mean, It wouldn't make sense to "skip" a version. You said you are using VS 2012, so it would be SSIS 2012. It think it can read only 2008 databases. The fact that you tested on the same server and it worked also makes this point stronger.