Excuse me but I am very new at learning to use oracle and sql.
I was given a bat file by my teacher that runs an sql to setup a database. The sql basically just drops 5 tables and recreates them with data.
What I don't understand is why I am seeing tons of other tables (that came with oracle?)
Why am I seeing all of these tables http://i.imgur.com/AvliJ.jpg
the only tables that are supposed to be created are
REP
CUSTOMER
ORDERS
PART
ORDER_LINE
Is there a way to only display those?
The other tables are tables Oracle uses.
Whether you see them or not depends on your permissions in the database. Ask your teacher to show you how to reduce your permissions so that you can only see the five tables your supposed to or look at the Oracle documentation here User Admin.
ETA : Be careful if you do start messing with permissions.
Related
I am using a SQL database and MS Access 2019 as the front end. The SQL database tables are linked to the Access db using an ODBC connection.
All my queries (they have multiple joined linked tables) run just fine, but as soon as I add a join to a table stored in the Access app (for example, a small table just for mapping values) the query will slow to a crawl. Doesn't matter if the joined fields are indexed or what type of join I'm using.
If anyone has seen this behaviour and found a solution I would much appreciate hearing it.
Joining tables from two separate databases requires the client app to retrieve both tables in their entirety in order to determine the rows needed. That's why it's slow.
If your Access table is small, try using a stored procedure on the SQL side with the data from Access moved to a temporary table. (Or better yet, move the Access table to SQL).
I know in Impala (and other databases) I can run both of the following:
SHOW DATABASES
SHOW TABLES
I also know I can add optional LIKE or IN arguments e.g. to show me all the tables in database Bananas I could write:
SHOW TABLES IN Bananas
What I really want to know is a way of returning all the tables in the databases without having to recurse through (also showing database name and table name in separate fields.
I'll be running this via impala shell so I'd have to first return back all the database names and then produce a script line per database to give me the tables.
It's not a problem to do this as such, I just can't help wondering there must be a better way to end up with:
Unfortunately not yet. Impala will eventually support this by exposing tables for schema metadata (e.g. ANSI INFORMATION_SCHEMA), and IMPALA-1761 tracks that feature request.
I'm working in a project where I need to make changes in the database to create a history of managers and status of projects and use it, instead of the already existing columns of managers and status in a projects table. The problem is: there are several aplications that may or may not be using those fields in this old table and would be almost impossible find all the aplications that use those fields to make them use the new tables.
So, I had been thinking, there is any way to create a stored procedure in a db2 database that can make the values in the manager and status columns in the projects table come from a query to the new history tables?
Sorry for my bad english.
I'm using MS Access 2013 and I have started learning SQL. I have written my SQL Database (all it does is make a bunch of tables) and I don't want to actually write anything in Access, I just want to bring in my SQL and request the Relationship Tables Diagram because my professor wants this particular diagram. Can someone tell me how to accomplish this? When I try to bring in my SQL it gives me errors saying that it was expecting INSERTS, DELETES, etc. but I don't have any actual data yet. I tried to look it up, but everything on Access and SQL is about making queries and I don't think that is what I'm after.
Your database schema should have the following.
1 - one create database statement
2 - one to x create tables statements
3 - primary keys for the each table
4 - foreign keys to express relationships.
5 - other object when business requirements need them.
http://en.wikipedia.org/wiki/Database_schema
Given this schema, the TSQL file can be loaded into any good modeling tool like ERWIN to generate a diagram.
If you want to do it from MS Access, you can. Behind the scenes, MS Access does support SQL in the query builder and you can use the table diagram window.
On the other hand, you can link MS Access to a SQL database (all tables) and still use the table diagram window.
I need to quickly implement a read-only database containing data pulled from two identically structured live databases.
The live dbs are actually company dbs from a Dynamics accounting system so I'm happy for any Dynamics specific advice but this is mostly a SQL question. It's a fairly old version of Dynamics from before Great Plains was acquired by Microsoft. This is on SQL Server 2000.
We have reports and applications which access the Dynamics data. These apps are designed to look at one company db. Now we need to add another. It's appropriate that most of these reports and apps see combined data. They don't really care which company an order or invoice exists in. They only look at a small number of the tables.
It seems to me that the simplest solution is to create a reports only db with combined data. Preferably, we need an efficient way to update this db with changes several times a day.
I'm a developer, not a db expert but here's my plan:
Create the combined reporting db with the required tables initially with the same table structure as the live dbs.
All Dynamics tables seem to have an int identity column called DEX_ROW_ID. I'm not sure what it's used for, (it's not indexed) but that seems like the obvious generic way to uniquely identify rows. On the reporting db I will change it to a normal int (not an identity). I will create a unique index on DEX_ROW_ID in all dbs.
Dynamics does not have timestamps so I will add a timestamp column to tables in the live dbs and a corresponding binary(8) column in the reporting db. I'm assuming and hoping that Dynamics won't be upset by the additional index and column.
Add an int CompanyId column to the reporting db tables and add it to the end of any unique indexes. Most data will be naturally unique even without that. ie, order and invoice numbers etc will be different for the two live dbs. We may need to make some minor changes to the applications but I'm not expecting to do much other than point them to the new reporting db.
Assuming my reporting db is called Reports, the live dbs are Live1 and Live2, the timestamp column is called TS and all dbs are on the same server ... here's my first attempt at an update script for copying the changes in one table called MyTable in Live1 to the reporting db.
USE Reports
CREATE TABLE #Changes
(
ReportId int,
LiveId int
)
/* Collect in a temp table the ids or rows which have been deleted or changed
in the live db L.DEX_ROW_ID will be null if the row has been deleted */
INSERT INTO #Changes
SELECT R.DEX_ROW_ID, L.DEX_ROW_ID
FROM MyTable R LEFT OUTER JOIN Live1.dbo.MyTable L ON L.DEX_ROW_ID = R.DEX_ROW_ID
WHERE R.CompanyId = 1 AND L.DEX_ROW_ID IS NULL OR L.TS <> R.TS
/* Delete rows that have been deleted or changed on the live db
I wonder if using join syntax would run better than the subquery. */
DELETE FROM MyTable
WHERE CompanyId = 1 AND DEX_ROW_ID IN (SELECT ReportId FROM #Changes)
/* Recopy rows that have changed in the live db */
INSERT INTO MyTable
SELECT 1 AS CompanyId, * FROM Live1.dbo.MyTable L
WHERE L.DEX_ROW_ID IN (SELECT ReportId FROM #Changes WHERE LiveId IS NOT NULL)
/* Copy the rows that are new in the live db */
INSERT INTO MyTable
SELECT 1 AS CompanyId, * FROM Live1.dbo.MyTable
WHERE DEX_ROW_ID > (SELECT MAX(DEX_ROW_ID) FROM MyTable WHERE CompanyId = 1)
Then do the same for the Live2 db. Repeat for every table in Reports. I know I should use a parameter #CompanyId instead of the literal but I can't do that for the live db name some I might generate these dynamically with a C# program or something.
I'm looking for any advice, suggestions or critique on what I'm doing here. I know it won't be atomic. Things could be happening on the live db while this script runs. I think we can live with that. We'll probably do a full copy either nightly or weekly when nothing is happening on the live dbs.
We need to favor performance over elegance or perfection. Some initial testing has the first query with the TS comparisons running at about 30 seconds for the biggest table so I'm optimistic that this is going to work but I'd also like to know if I'm missing something obvious or not seeing the forest for the trees.
We don't really want to deal with log files on the reporting db. Can we just set that to simple recovery model and forget about logs?
Thanks
I think there are a couple open questions here.
Do you need these reports to be near-real-time? Or is this this sort of reporting that could live with daily updates? But assume you need up-to-the-minute data.
Have you considered querying the databases directly and merging the data per-report on the fly? You'll have to do a lot of reporting to duplicate the effort that's going to go into designing, creating, and supporting a real-time merged replicated database.
Thirty seconds is (IMHO) unacceptable for any single query against a production database. There could be any number of tuning-related reasons for taking this long, but it at least means you're going to need serious professional SQL Server optimization resources (i.e. people). And if this is a problem for the queries for reports, it doesn't bode well for the queries to maintain a separate database for reporting.
Tuck into the back of your mind the consideration that, if you need to consolidate to a single database, it's worth considering whether you should make it an OLAP database rather than a mirror. The mirror will be quicker and easier, but the OLAP would be far more flexible and powerful in the long term; and it might be well to go the whole way from the beginning.
The last thing I'd want to do is write a custom update script. Try these bulletproof methods first:
Let's hope your production databases are backed up. Restore those backups every night to the reporting server. You can automate restores with the RESTORE command, which will work with a file on a network server.
Use SQL Server replication to push data from the live servers to the backend.
Schedule a DTS package every night to import the entire production database.
This might seem like brute force. But since you're copying a 2000-era database, brute force cannot be a problem with today's hardware. As an added advantage, these methods can be supported by a sysadmin instead of a developer.
Method 1 has the added added advantage of serving as backup verification. :)