I have two Databases, one which looks at Financial Year 2018- 2019 and another which will be looking at Financial year 2019-2020.
Now these are Sage Databases so they have a lot of Tables within each of them, the setup of each Database is exactly the same.
Now I had a report which looked at the current financial year no problem, but I didn't realise that they had it set up as the previous financial year would be stored in a separate Database.
I've said "View" within my title, but that's not really what I need as I need whole tables.
So my question is this, is there a construct within SQL that will allow me to create a new datasource of some kind which contains the 12 tables I actually need to populate my report and the data inside these tables be a union of the 12 tables from 18-19 and the 12 tables of 19-20.
I hope that make a least a little sense.
(I would just try and make use of a view, but there's multiple datasets within the report which make use of the joins in slightly different ways)
Related
We have a legacy ERP system that stores data in flat files. we have replicated these flat files in SQL Server database pretty much as it is.
Some of the sales tables store historical data in multiple columns without storing any dates with them. the name of the column will tell us which month the sales data belong to. Sales01 is current month, Sales02 is previous month, Sales03 is the month before and so on. Same with sales Qty and margin. i.e. Qty01, qty02 and margin01 and margin 02 and so on. This is repeated for each customer and each item sold.
Now, I am working on a small project where I have to design a small DB for reporting with some tables that will be fed by this main database.
I want to load this data in such a way that these values from each month are stored in rows with a month-year or date from first day of the month in another column so I can use where clause with dates.
Not sure what would the be best way to go? I have written a stored proc in the past to load this data this way, but wonder if there a better way to go.
Some how I can use SSIS Pivot transformation?
or just use Pivot or similar statement to do this in an SP?
I will most likely be using this practice to built a data warehouse in future.
OK, first question here so go easy!
Let's start with some quick background - I have been working with Crystal almost daily for the past 15 years to so, so I like to think I am not too much of a dummy.
Today, I have stumbled across a problem I have never seen.
My source data is from SQL Server 2012 Standard.
I have created a view, nothing too complicated. It grabs PartNo and Description from an Inventory Main table. Then a few other columns from other related tables so I can see the data neatly in a single view, so stuff like carton qty (how many units go into 1 carton), height, length, depth.
Now, bear in mind I have done these kinds of views so many times in the past I couldn't even count.
Now, in Crystal Reports 2013, I connect to SQL via OLE using sa credentials, find my view. Pop over to the "Links" tab in the Database Expert, and my columns created from the related tables are not listed! Only PartNo and Description are visible.
I have scratching my head over this for the past few hours & the only thing I can put it down to is some kind of weird Microsoft update.
My SQL view results:
SQL view
What I see in Crystal
Database Expert, Links
the other way to test this is instead of a view or table just add a
command and select * from yourview
the only downside i think would be using sql expression from a command connection.
another option is to
To define the data type in the view... same with dates. does not like
to be converted otherwise will treat it as a string
The setup
I have the following database setup:
CentralDB
Table: Stores
Table: Users
Store1DB
Table: Orders
Store2DB
Table: Orders
Store3DB
Table: Orders
Store4DB
Table: Orders
... etc
CentralDB contains the users, logging and a Stores table with the name of each store database and general information about each store such as address, name, description, image, etc...
All the StoreDB's use the same structure just different data.
It is important to know that the list of stores will shrink and increase in the future.
The main client communicating with this setup is an API REST Service which gets passed a STOREID in the Header of each request telling it which database to connect to. This works flawlessly so far.
The reasoning
Whenever we need to do database maintenance on one store, we don't want all other stores to be down.
Backup management should be per store
Not having to write the WHERE storeID=x every time and for every table
Performance: each store could run on its own database server if the need arises
The goal
I need my REST API Service to somehow get all orders from all stores in one query.
Will you help me figure out a way to do this without hardcoding all storedb names? I was thinking about a stored procedure on the CentralDB but I was hoping there would be other solutions. In any case it has to be very efficient.
One option would be to have a list of databases stored in a "system" table in CentralDB.
Then you could create a stored procedure that would read the database names from the table, loop through them with cursor and generate a dynamic SQL that would UNION the results from all the databases. This way you would get a single recordset of results.
However, this database design is IMHO flawed. There is no reason for using multiple databases to store data that belongs to the same "domain". All the reasons that you have mentioned can be solved by using a single database with proper database design. Having multiple databases will create multiple problems on the long term:
you will need to change structure of all the DBs when you modify your database model
you will need to create/drop new databases when new stores are added/removed from your system
you will need to have items and other entities that are "common" to all the stores duplicated in all the DBs
what about reporting requirements (e.g. get sales data for stores 1 and 2 together, etc.) - this will require creating complex union queries...
etc...
On the long term, managing and maintaining this model will be a big pain.
I'd maintain a set of views that UNION ALL all the data. Every time a store is added or deleted those views must be updated. This can be automated.
The views provide an illusion to the application that there is only one database.
What I would not do is have each SQL query or procedure query all the database names and create dynamic SQL. That would entail lots of code duplication and an unnecessary loss of performance. This approach is error prone. Better generate code once in a central place and have all other SQL code reference that generated code.
I am using Vb 2008 express edition and am very new to treeviews. i have basic knowledge of how to connect to a database. the database i am working with is a microsoft access database and has a large amount of tables with various information. two of these tables i need to put into a treeview. one has 2 columns called date and date id, the date will be the main nodes on the treeview. the other table has 8 colums, among them are the corresponding date id's from the first table, the purchase order id and the purchase order number. the child nodes will be the purchase order number.
Now i know there are a bunch of tutorials out there on treeview population through microsoft access databases but i have found none specifically with what i need, they are all just about dumping ALL the data from the database into the table. i just want specific contents of two tables. if someone could help me out with this i would be very grateful. i can give more information if needed on what i am working with or anything else.!
This is an example of what it needs to look like. i am upgrading this program from vb6 to vb.net which is why i already have the program.
What you will have to do is loop through the first table (using sql and a datareader, for example) and then create the initial (parent) nodes. (Note that the below is a general idea, you will have to figure out the loop and datareader parts).
looping structure
TreeView1.Nodes.Add(nodeName, nodeName)
next record
Then, loop through the second table, adding the record to the correct node...
looping structure
TreeView1.Nodes(parentNodeName).Nodes.Add(nodeName, nodeName)
next record
The project I'm working on tracks data on a year by year basis. The user will log into the system and specify the year it wants to access the data of. For example, the user could specify the year 2004, and the .jsp pages will display 2004 data.
My problem is that from 2013 onward, the data for one .jsp page will be different, and the current database table schema needs to be modified, but backwards compatibility for the 2012 and before years needs to be maintained.
Currently (2012 and before), the relevant database table displays two columns, "continuing students" & "new starts" that is displayed by a single .jsp. For 2013 and onward, 4 columns need to be displayed. The original two columns are being split into two subcategories each, undergrad and graduate. So I can't simply add those new columns to the existing table because that would violate third normal form.
What do you think the best way to manage this situation? How do I display the new data while still maintaining backwards compatibility to display the data for older years?
Some options:
Introduce the fields and allow for nulls for older data. I think you rejected this idea.
Create new table structures to store the new data going forward. It's an least an option if you don't want (1). You could easily create a view that queries from both tables and presents a unified set of data. You could also handle this in the UI and call two separate stored procedures depending on the year queried.
Create a new table with the new attributes and then optionally join back to your original table. This keeps the old table the same and the new table is just an extension of the old data. You would write a stored procedure potentially to take in the year and then return the appropriate data.
One of the things to really consider is that the old data is now inactive. If you aren't writing to it anymore, it's just historical data that can be "archived" mentally. In that case I think it's ok to freeze the schema and the data and let it live by itself.
Also consider if your customers are likely to change the schema yet again. If so, then maybe (1) is the best.