We receive bulk data from our customers in a spread sheet. I loaded them in a temporary table as of now. I tried to normalize the data and create a parent table and each parent to have 4 or 5 child rows. Is there a way to insert all the parents and their children using queries? I dont want to write an Application to do that
If you're specifically looking to write only queries to perform this task, check out the following article that outlines a way to set up a linked server to an excel doc.
http://www.sql-server-helper.com/tips/read-import-excel-file-p01.aspx
If you get this set up correctly (which can be a pain) it's as easy as querying the data directly.
Related
I need to query a SQL table and pull rows if the value in column NDC_CODE is among my list of values.
The problem is that my list is in the thousands and I'm not sure how best to code this.
I know I can excel-fu/concatenate/copy-paste a 'where' statement together:
where RX_NDC.NDC_CODE in (‘ndc1',’ndc2’,'ndc3',…,’ndc8523’)
My questions are:
if I run the code with the where statement as above, manually listing out thousands of values, will use a lot of resources and brick the server?
Is it possible to create a "subset" locally that I can reference in the code instead and have this subset persist across multiple queries?
I read about creating temporary tables, but I only have read-only access to this database. Is there some way to create a temporary table locally and reference this in my query?
I have a table with 5 fields that are all the same. They each can hold a reference to a row from another table with relationships. I want to update all of these fields at the same time on a row, but with a randomly selected row from the table for each field (with no duplicates). I am not sure how in access SQL you can update a lookup/relationship field like this. Any advice is greatly appreciated.
Simple answer is that you can't, not as it appears you would like to anyway. The closest thing possible would be to create an Insert query with parameters, and then feed in your 5 values using VBA. Since you will have to use VBA anyway, you may as well go the whole hog and conduct the entire process with Recordsets.
But that's not the fiddly part, (relatively speaking) selecting your source values is. What you will need to do is open a Recordset on your source table, and hook it up to your random-no-duplicates logic in order to select your 5 record references, then you open up a Recordset on your destination table, and drop them in the appropriate fields.
This tutorial will get you started on Recordsets: http://www.utteraccess.com/wiki/index.php/Recordsets_for_Beginners
I am trying to do this:
Concatenate many rows into a single text string?
And I want to have the query results join against other tables. So I want to have the csv queries be an indexed view.
I tried the CTE and XML queries to get the csv results and created views using these queries. But SQL Server prevented me from creating an index on these views because CTE and subqueries are not allowed for indexed views.
Are there any other good ways to be able to join a large CSV result set against other tables and still get fast performance? Thanks
Other way is to do materialization by yourself. You create table with required structure and fill it with content of your SELECT. After that you track changes manually and provide actual data in your "cache" table. You can do this by triggers on ALL tables, including in base SELECT (synchronous, but a LOT of pain in complex systems) or by async processing ( Jobs, self-written service, analysis of CDC logs and etc).
I have a parent row and child rows on 7-10 separate tables, with a unique key tying the rows on the child tables to the parent row. For a search feature, I need to retrieve the parent and all the matching child rows, based on a query against the data in the parent table. There are up to 5000 matching parent rows. Currently we are re-running the query against each of the child tables, like:
select data from child
where key in (select key from parent where search_criteria)
This seems pretty inelegant especially as we continue to add more child tables. Is there a better way to do this in DB2?
Some of my thoughts:
Will DB2 reuse the results of that select? What about if there is a high volume of queries?
I know the keys after the parent query, so I could pass them in the SQL, but that SQL would get crazy with 5000 keys, and presumably exceed the SQL limit.
Would it be worth it to store the keys as a temp table, or would the setup / teardown be excessive?
This sounds like an ideal scenario to use a RPG program and use a stored procedure that calls/consumes it. This way, you're not making so many round trips. Pass your search criteria to the stored procedure and the stored proc invokes the RPG program. Let RPG chain the 'files' together, which would speed up your query.
I need to create a sql stored procedure (Sql Server 2008 - T-SQL) which copies a node in an adjacency model.
Table can be seen as having two columns, Id and ParentId (FK to Id). Copying means that also all subordinates need to be copied.
I think that using WITH is a good start, but I'm curious if I can do this copy without using Cursors.
The fundamental problem with adjacency lists is there is no general way in SQL to extract an entire sub tree, so you already have a problem of identifying all the rows you need to duplicate without resorting to a cursor.
If possible migrate your adjacency list to a nested set model which allows you to easily identify all the nodes of a subtree. However, the maintenance of a nested set model is more complex for general inserts and deletes.
EDIT: As pointed out by 'a_horse_with_no_name' there is a way in general SQL to process adjacency lists, recursive common table expressions.
Copying a whole sub-tree is a bit of a problem because when you copy your sub-tree you are either
denormalizing data or
using it as a template of some sorts.
In either case you are dragging data through inconsistent state at some point - which indicates some problems with your design (for example do your records need to have multiple parents or not? if yes, then you should consider redesigning).
So, you should update the answer with a more complete example of what you are trying to do.
One solution would be to have a temporary table, selecting for the insert should not be a problem, it is just updating the referenced IDs that would be a problem.
So
WITH INSERT into temporary table
UPDATE the IDs
INSERT into original table
DELETE temp records
The procedure needs to go like this because it would be hard to change the IDs (both record IDs and ID referring to parent) in initial WITH INSERT. However it might be possible, if there was a nice function that depended only on max_id or only on old IDs.