Is there a way to make a schema diagram from an SQL Server database using the stored procedures of this database?
I don't mind if I must use an external software.
You could try playing around with CodeSmith Generator. It's SchemaExplorer Schema Discovery API allows you to programmatically access database elements for a given database and do something creative with it. However, it will still be logically hard to reverse-engineer a schema/diagram this way.
You can build a SQLCLR procedure which uses the Scripter Class from the SMO library.
update: more info on the question reveals the idea is to generate a table schema with dependencies based on the content of the stored procedures.
The approach would be to generate the table structure from the information_schema views and then parse the contents of the syscomments table to figure out the relations. This will always be approximate as it is very hard to establish the one-to-many relationships purely from the SQL Statements. I think you can make a guess based on the field which is referenced more.
If you can't see the tables then you can not generate the schema.
That is, you can't if you have permissions on stored procedures only.
At least two reasons:
the stored proc may JOIN and use several tables
you can't see constraints, indexes, keys etc even if you had table names
Basically, you can only:
see what you have permissions on in SSMS etc
see the internals if you have VEIW DEFINITION rights
Edit, after clarification
There is no way to script implied aspects (such as missing foreign keys) of the schema from code
Related
What are some ways that these two databases can [INSERT INTO] Between each other or use commands or display the data in the table of the two databases ?
Not directly, but there are ways...
What you're asking about is called "cross database queries".
Each database in PostgreSQL has its own system tables and ways of keeping itself organized. Queries between two databases can break this, even for databases hosted by the same database server.
But there are ways to achieve what you want
Single database, multiple schemas
Instead of two databases, you can run one database with two schemas. The keeps the tables, views, etc separated and easier to maintain, and allows queries between the two. It also allows security and data isolation for users who are only allowed to access one of the schemas.
You're actually already using a schema in PostgreSQL called "public"; adding more schemas simply extends this.
See the documentation.
Foreign Data Wrappers
Foreign Data Wrappers (fdw) allow you to "link" a schema (or just tables, if you prefer) in another database. See the documentation for CREATE SERVER, and this seems like a pretty clear blog post on the subject.
Note that Foreign Data Wrappers will allow you to link to other databases than just PostgreSQL e.g. Oracle, SQL Server, MySQL, and lots more. See here.
I need steps to change my default [dbo] schema to some custom schema say [TEST] in SQL Database. I figured out some of the steps and want to make sure is there any other objects or procedure i should be aware of while migrating the schema.
I need to change the schema name for all my tables, views, functions, store procedures from [dbo] to [TEST].
Is there any other Sql objects i should consider while performing this migration?
There are quite a few potential areas to look at.
At lot will depend on what is in use in your DB.
Things to look for:
Triggers
User Defined Datatypes/Tables
Synonyms / Server Links
Partition Functions / Schemas
Then you may have SSIS,SSRS and SSAS dependencies which you might also want to change...
Whether or not you need to change any of this will be dictated by the exact reason you are moving to a different schema.
If this is something that you plan to do on a regular basis - it might pay dividends to look at your MODEL DB - you might be able to get some quick wins by changing some options here. NB - I wouldn't try this on a Production server !!!
rgds
John
I am trying to get everything
find all the tables, views, stored procedures, scalar functions, table functions, schema using sql query of a specific database
I actually wanted to create a autocomplete option but as of now my first step is to get everything in a list but not sure how i will get all of the above of a specific database
This is a bit long for a comment.
You need to look into the system tables. Personally, I prefer the standard INFORMATION_SCHEMA views, but the information you want is spread out.
In SQL Server, you can use sys.objects, paying attention to the object type. The place to start learning about it is in the documentation.
I'm working on a AS400 database and I need to manipulate library/collection with sql.
I need to recreate something similar to the CLRLIB command but I don't find a good way to do this.
Is there a way to delete all the table from a library with a sql query ?
Maybe I can drop the collection and create a new one with the same name. But I don't know if this is a good way to clear the library.
RESOLVE :
Thanks to Buck Calabro for his solution.
I use the following query to call the CLRLIB in SQL :
CALL QSYS.QCMDEXC('CLRLIB LIB_NAME ASPDEV(ASP_NAME)', 0000000032.00000)
Where LIB_NAME is the name of the library I want to clear, ASP_NAME is the name of the ASP where the library is and 0000000032.00000 is the command lenght.
(note that the term COLLECTION has been deprecated, SCHEMA is the current term)
Since a library can contain both SQL and non-SQL objects, there's no SQL way to delete every possible object type.
Dropping the schema and recreating it might work. But note that if the library is in a job's library list, it will have a lock on it and you will not be able to drop it. Also, unless the library was originally created via CREATE SCHEMA (or CREATE COLLECTION) you're going to end up with differences.
CRTLIB creates an empty library, CREATE SCHEMA creates a library plus objects needed for automatic journaling and a dozen or so SQL system views.
Read Charles' answer - there may be objects in your schema that you want to keep (data areas, programs, display and printer files, etc.) If the problem is to delete all of the tables so you can re-build all of the tables, then look at the various system catalog tables: SYSTABLES, SYSVIEWS, SYSINDEXES, etc. The system catalog 'knows' about all of the SQL tables, indexes, views, stored procedures, triggers and so on. You could read the catalog and issue the appropriate SQL DROP statements.
I'm trying to find out if this is possible, but so far I haven't found out any good solutions. What I would like to achieve is write a stored procedure that can clone a database but without the stored data. That means all tables, views, constraints, keys and indexes should be included but without any data. Can it be done?
Sure - your stored proc would have to read the system catalog views to find out what objects are in the database, determine their potential dependencies, and then create a single or a collection of SQL scripts which re-create the database, and execute those.
It's possible - not very nice and easy to do. Especially the dependencies between objects might cause more headaches than first meets the eye....
You could also:
use something like SQL Server Management Studio (if you're on SQL Server - you didn't specify) and create the scripts manually, and just re-execute them on a separate server
use a "diff" tool like Redgate SQL Compare to compare two servers and have the second one brought up to date
I've successfully used the Microsoft SQL Server Database Publishing Wizard for this purpose. It's pretty straightforward, no coding needed. Here's a sample call:
sqlpubwiz script -d DatabaseName -S ServerName -schemaonly C:\Projects2\Junk\ DatabaseName.sql
I believe the default is to create both data and schema, but you can use the schemaonly parameter.
Download it here
In SQL Server you can roll through the system tables (sys.tables, sys.columns, etc.) and construct things one at a time. It's going to be very manual and error prone at the beginning, but it should become systematic pretty quickly.
Another way to do it is to write something in .Net using SMO. Check out this link:
http://www.sqlteam.com/article/scripting-database-objects-using-smo-updated