I use SQL Server SMO methods to get SQL Server data such as list of databases.
Is there way to execute above action using ADO.net without sending TSQL parameter to SQL Server?
You can also inspect the system catalog views, e.g.
SELECT * FROM sys.databases
to get a list of databases, or
SELECT * FROM sys.tables
to get a list of tables inside the current database.
Read all about the system catalog views on MSDN.
But I don't understand what you mean here:
Is there way to execute above action using ADO.net without sending TSQL parameter to SQL Server?
???? what exactly (and why?) do you not want to send to ADO.NET or SQL Server?!?!? Please elaborate....
Related
I'm coming from an environment where I have used only MS Access and have linked spreadsheets as tables - the spreadsheets are updated daily then "ETL'd" and sent into various tables in Access via SQL queries that I've written.
Is there a way to do that in SQL server? I am brand new to SQL Server and although I can write a mean query - I don't know the SSMS environment intimately yet.
Thanks!
You can use SSIS, but for simple tasks, I often use views and OPENROWSET (or just OPENROWSET in queries), to query external sources. For example:
CREATE VIEW MyExcelFile
AS
SELECT rs.*
FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0',
'Excel 12.0 Xml;HDR=YES;Database=C:\path\to\my\file.xlsx',
'SELECT * FROM [SomeNamedRange$]') rs
This does require the Excel file to be accessible from the server, of course. It uses the Access Database Engine to query the Excel file. Note that some DBA's prohibit ad hoc access to the Access Database Engine for security reasons.
I need to query a hp vertica database from SQL Server stored procedure. It is a join query and If I use linked server, it is going to fire as 2 separate selects and join it in the SQL Server . Is there any way I can use ODBC to fire the join query to Vertica from TSQL and get the processed result set back into an SQL table.?
Any other approach to suggest to achieve this ?
You may need to use OPENQUERY syntax in SQL Server, to get the full query sent to Vertica for execution there... There are other possibilities, but we'd need much more detail about what you have in play (especially but not only your current query) to usefully discuss them.
We have a SQL Server database setup with a Linked Server setup connecting to a Progress OpenEdge database. We created a SQL Server view (for using with SSRS) of some of the OpenEdge tables using code similar to the following:
CREATE VIEW accounts AS SELECT * FROM OPENQUERY(myLinkedServerName,
'SELECT * FROM PUB.accounts')
CREATE VIEW clients AS SELECT * FROM OPENQUERY(myLinkedServerName,
'SELECT * FROM PUB.clients')
For some reason the queries seem to bring back the whole table and then filter on the SQL side instead of executing the query on the Progress side.
Anybody know why or how to remedy the situation?
Thanks
Is it any faster when executed as a native OpenEdge SQL query? (You can use the sqlexp command line tool to run the query from a proenv prompt.)
If it is not then the issue may be that you need to run UPDATE STATISTICS on the database.
http://knowledgebase.progress.com/articles/Article/20992
You may also need to run dbtool to adjust field widths (OpenEdge fields are all variable width and can be over-stuffed -- which gives SQL clients fits.)
http://knowledgebase.progress.com/articles/Article/P24496
I have two databases, one MSSQL and the other in Access.
Right now, inside the access file, the mssql tables are set up as linked tables so queries can be written using tables from both databases. (e.g. "select * db1.table1 where db1.table1.somevalue not in db2.table1", or select into tables like that one)
These queries need to be moved into a VB.NET project, but still be linked to the access file.
I think what I am needing is a Database object that can have tables from 2 different connections, (ie the SqlClient and OleDb connections)
Is this possible? If so, how? Or do I need to rewrite the queries using loops or something?
What I would do is query your access database to get some result set and that pass that result set as a parameter to a stored procedure in your MS SQL database. You would just have to transform your results from access into XML to be passed as a xml variable as a parameter. And then in your stored procedure you can convert the XML to be a table variable and you can use it just like a regular table.
THere is no reason you can't create an MS Access .mdb with Links to your MS Access Database and your SQL Server database
Access Db #1 Contains Access Tables and Data.
SQL Db Contains your MS SQL Tables.
Access Db #2 contains links to the tables in Access DB #1 as well as links to the tables in your SQL Server Db. This .mdb files ALSO contains your query defs required by your vb.net project.
I'm pretty sure you can just connect to the Access database. All the internal objects--including the links to SQL Server tables--should be accessible to your vb.net project.
How to get the results (pass parameter also) of a view of a remote server from a stored procedure?
The view is in a separate server from the current server where the stored procedures exist.
Thanks.
You could use the Linked Server feature of SQL Server inside your stored procedure:
A linked server configuration allows
Microsoft SQL Server to execute
commands against OLE DB data sources
on different servers. Linked servers
offer these advantages:
Remote server access
The ability to issue distributed
queries, updates, commands, and
transactions on heterogeneous data
sources across the enterprise.
The ability to address diverse data sources similarly.
You would have to write your query inside your stored procedure this way for example:
SELECT *
FROM MyRemoteServer.MyDB.dbo.MyView
WHERE MyViewColumnX = #ParameterY
Create a linked server on your main SQL Server, creating the link to your remote server.
The fact you have a view on the remote server is good, it provides a layer of abstraction to your data. You can specify a login for the linked server that has permission to read that view only. You could also modify the view in the future (add a "where" clause for example to improve performance) with no front end changes required.
I would also add another view on your main server that selects from the view on your remote server: -
create view vwMain as select col1, col2 from RemoteServer.DB.dbo.RemoteView.
That way you can reference vwMain throughout your code (within many stored procedures) without continually referencing the remote server. This way, should your remote server change or you move the data to your main server, it is one simple change to vwMain and all your code continues to work.