I'm having trouble performing a query on a remote Oracle SQL Server via Excel VBA while trying to perform an INNER JOIN in the same query with a local table in a Excel file sheet.
Example:
Excel Sheet with local table ["LTE_Cells$LTE_Cells_Tmp"]:
Sheet "LTE_Cells"
Oracle SQL Query
SELECT a.STARTDATE, a.ENODEB, a.EUTRANCELLFDD, (a.COUNTER_1/8/1024)+
a.COUNTER2/8/1024) AS Total_Total_Traffic_TB FROM »»»LOCAL_EXCEL_TABLE««««
INNER JOIN REMOTE_DATABASE.LTE_KPI_1 a ON
((»»»LOCAL_EXCEL_TABLE««««.EUTRANCELLFDD =
REMOTE_DATABASE.LTE_KPI_1.EUTRANCELLFDD) AND
(»»»LOCAL_EXCEL_TABLE««««.ENODEB = REMOTE_DATABASE.LTE_KPI_1.ENODEB)) WHERE
(((REMOTE_DATABASE.LTE_KPI_1.STARTDATE)>=sysdate-3));`
Thanks in advance for the help!
This doesn't answer your question directly, and I may be all wet on this but I don't know that either Excel or Oracle explicitly handles what you are trying to accomplish.
However, MS Access will out of the box. Short answer: I think you are using the wrong tool for this task. You are using the proverbial hammer to saw a board in half. Link the spreadsheet and the Oracle table as linked objects in Excel, and your query should be easy-peazy.
Longer answer: while Access does this simply and easily, it can and probably will leave a path of destruction behind it on the DBMS. Specifically, you can expect to thrash the shared pool in Oracle, as Access will be issuing one query (using literals, no less) for every line in Excel. For 1,000 lines, it probably doesn't matter that much, but if you're going to do this on really large datasets, you will make a fast enemy out of your DBA.
Extended answer: really, the best way to do this is to load the contents of those Excel spreadsheets in Oracle tables and let the DBMS do the heavy lifting. This is bread and butter for the RDBMS.
Related
I have T-SQL queries stored on a hard drive: I:\queries\query1.sql and I:\queries\query2.sql.
I usually work in a way that I execute a query from a drive, and then I copy results into Excel, and then I work on it.
My problem here is that query1.sql is already long, and now I would like to extend it by getting a result of query2.sql, and join it with a result of query1.sql.
What I could do is appending a code from query2.sql to query1.sql. But then the query is getting really long and hard to maintain.
I would like to do something like this:
SELECT * FROM ("Result of I:\queries\query1.sql") q1
LEFT JOIN ("Result of I:\queries\query2.sql") q2 ON q1.ID=q2.ID
Is there any way to write a query or stored procedure, which will be again stored on a drive to do this?
Basically, you need to ask your DBA for a database when you are able to store things in the database. This can be on the same system where the data is stored. Or, it could be on a linked system. Gosh, you could run SQL Server locally and store the information and data there.
Then, the queries that you are storing in files should be views in the database. You can then run the queries and store and combine the results locally.
You are essentially recreating database functionality using text files and data files -- going through a lot of effort when SQL Server already supports this functionality.
To expand on Gordon's comment (+1), why are you running scripts off of a drive? Most DBA's I've known would treaten bodily harm over this as executing code that they can't control / troubleshoot / see source code control on brings a whole host of security and supportability issues.
Far better to store this code in a Stored Procedure, which will have a saved query execution plan, can be tracked using various DMV's, and have permissions assigned to it, then your outside Excel doc can just set a connection and execute the SP.
Good morning,
I just received a new assignment and I am struggling with finding an appropriate solution. I have searched through the SO Forums, and through Google, but have not found a workable solution. Below is my scenario:
We are working out of Microsoft Access to connect to an SQL Server Database via an ODBC Connection.
I wasgiven an incredibly large pass-through SQL query, larger than is able to be processed in MS Access. In this pass-through query, there is a subquery in a WITH...AS method.
I am hoping to be able to split this one, singularly large, SQL pass through query into two: Query One (the subquery), and Query Two (which references the results of the subquery)
I know that by using general Access queries, I can write a Macro like follows...
Sub myQuery()
' Edited from http://www.dbforums.com/showthread.php?1667831-Run-multiple-queries-in-sequence-on-click
' On Error GoTo ErrHandler
' Run the first query
MsgBox "Starting first query"
DoCmd.OpenQuery "first_Query"
DoEvents
' Run the second query
MsgBox "Done. Now starting second query"
DoCmd.OpenQuery "second_Query"
DoEvents
MsgBox "Done!"
End Sub
However, these need to be pass-through queries. I believe that the enormously large SQL String is created via a number of user inputs. Regardless, I don't have the ability to change the pass-through SQL that I was given.
Is there anyway I can write a macro that calls the first pass-through query, and then calls the second pass-through query that REFERENCES the result of the first?
Here is an example with what I am working with...
WITH queryOne AS
(
SELECT fooID
FROM tblFoo
WHERE foodate > ...
)
SELECT foo, fooone, footwo, foothree
FROM tblOtherFoo
WHERE fooID = OtherFooID
However, the query is 50000+ characters, exceeding that ~37k limit.
Please feel free to ask any questions. I am stumped by this and would appreciate any feedback or alternative resources.
Thank you!
It not clear what you mean by something that references the first or previous? Why break up something you been given that supposed works just fine?
So just place that existing t-sql you been given into a stored procedure. In T-SQL you can easy have some SQL operate on some previous SQL, but why break up such a HUGE massive monster slew of code and introduce bugs? It will take you YEARS AND YEARS to break up a KNOWN working huge T-SQL that been built and developed for you (something that long likely took a few years and a team of developers to create).
A conservative estimate would be such a routine cost $50,000, or even $100,000 to develop.
No question that the working T-SQL you been given might reference previous data, or even do selects into #Temp tables that additional T-SQL can work on.
If you ALREADY have a working PT code and query given to you?
Simply take that T-SQL query, and simply paste it into a stored procedure. You will do this in SQL Server and NOT even touch or bother with Access.
So don't create some macro in Access that calls multiple separate queries, but place all of the T-SQL in a stored procedure, and simply call that huge mess one time from Access.
It possible that the T-SQL you been given is incorrect, but assuming that the T-SQL is correct, then simply place all that long mess into a working stored procedure. You do not place this SQL in MS Access and you don’t need to have that mess inside of Access.
So get that T-SQL working in SQL Server – don’t bother with MS Access until this long query mess is working in SQL Server. ONLY THEN do you fire up Access.
So you THEN create a simple PT query in Access that calls the huge long T-SQL mess you been given. But that “mess” is to be placed in SQL Server – not in Access.
So create a PT query in Access that calls your “supposed” working T-SQL you been given. The SQL you save in the Access PT query will be this
Exec my_StupidLongSQLProc
Save the above as a PT query. Then in VBA code go:
Currentdb.QueryDefs("MyPTQuery").Execute
If you need to pass some values from Access, then go:
With CurrentDb.QueryDefs("MyPTQuery")
.sql = "exec My_StupidLongSQLproc " & p1 & "," p2
.Execute
End with
In above we pass two VBA values from Access to the big mess of sql you have – the stored procedure in above is just an example that access two parameters passed from Access VBA. If the T-SQL you been given does not require values from Access, then the first single .execute will do the job.
And if you REALLY did get such a long routine that is correct T-SQL, then it likely already has parameters in the working T-SQL (and again you don’t want to mess with or change such a huge long working T-SQL that you been given).
So you only need one line of code in Access, and your existing long T-SQL you been given if written correctly can be placed in a stored procedure (assuming that you actually been given a correctly working PT query).
So if you REALLY did get a huge massive working T-SQL statement, then simply place that KNOWN AND WORKING T-SQL in SQL Server as a stored procedure and call it with one line of code as per above.
So trying to split this up from Access will only server to cause world-wide poverty and ANY tiny miss step or breaking up of that huge long routine will cause world-wide poverty and starving children as you try and “fix” this great working T-SQL that you been given. As noted, something that long to create would take a teams of developers HUGE resources. If you touch or break up one line of code and mess it up, then you need that team of developers to spend several months trying to fix what you broke.
So the INSTANT you start breaking up such a huge long mess is the instant you lost this battle and will waste several years of your life trying to fix this crazy long T-SQL that you been given that is already claimed to be proper working code.
I'm playing around with a table in an MS Access database. The table has a primary key of CLIENT_NUMBER. My corporation maintains an Oracle database that has a table which contains clients contact information (address, phone numbers, emails, etc). It also has the CLIENT_NUMBER field. I got to thinking that maybe I can join the 2 tables from the different databases and run some queries. I dug around on the net and I couldn't really find any reference, so I think this is a long shot and a silly question, but is that possible? Maybe through a DB link or something? For reference, I use SQL Developer 3.2.xx for sql developing.
I would copy the table in oracle to Access using what's called a sqlpassthrough query in Access. linked tables to oracle in my experience, perform very poorly, and if you are also thinking about joining to a local table in Access, probably much worse.
Passthrough queries are very quick since Access simply just sends the query for execution to the target server/database based on the connection you identify for the passthrough query, hence the name "pass-through".
The driver in the connect string may not work for you, and it may need more info depending on how things are setup in your environment, so you will have to work that out.
'creates the passthrough query to oracle
With CurrentDb.CreateQueryDef("qOracleConn")
.Connect = "ODBC;Driver={Microsoft ODBC for Oracle};Server=oracleservername;Uid=oracledbusername;Pwd=oracledbpassword;"
.sql = "SELECT * FROM tableinoracle"
End With
'creates the local table in access
CurrentDb.Execute "SELECT * INTO OracleClients FROM qOracleConn"
I have a table (tbl1) in an Excel file with about 70k rows. I have linked that table into Power Pivot. There is another table (tbl2) in SQL Server with millions of rows that I need to left join to the table in my Excel file on
tbl1.[Member Number] = tbl2.[memid]
What query should I use to do it without having to import the whole tbl2 from SQL Server (throws error on Power Pivot due to memory constraints)?
Preferred environment is Power Pivot, but I do have SQL Sever Management Studio. I don't have WRITE permission in the server where tbl2 is located. I do however have WRITE access in a different server.
Thank you!
Import the Excel file into the SQL server where you have WRITE access, do the join there and import the data from this server. Any problem you see with this approach?
A few options spring to mind:
Get more memory/64 bit Excel and use PowerPivot as you are currently trying to do. If you are working on 32bit excel then you are effectively constrained to using 1gb of RAM whereas on 64bit you can use everything you've got. 64bit Powerpivot can potentially deal with hundreds of millions of records.
Read the SQL data and your csv into R, do the join and either write the output to your WRITE db or save as CSV to feed into PowerPivot. Although R has a steep initial learning curve, doing this kind of thing with the dplyr library is straightforward.
Dump your SQL table to csv and read both that your current csv into the WRITE db and do the join in your PowerPivot SQL query.
Which works best probably depends on the skills you have and how often you are doing this. I'd probably go down the 'R' route as you can set it up as a scheduled job.
I have an SQL Query I'm using to Pull Beds by Unit and the related Number of Beds in Use and Available.
What is the SQL Syntax to have the results of the query save to an excel file (existing or new).
Please Note: I have been searching and I can't believe this isn't easy to figure out. Lots of people seems to use other tools but I want to do it in SQL Stored Procedure - Is this possible?
Thanks so much for your help!
The easier way to do this is from Excel, utilize a connection to your SQLDB and then pull the data into excel, that is the most efficient way to do it.