I have some dbf files of foxpro database. However, I have no idea about what are relationship between tables regarding foreign key, what tables are inter related and so on. Is there any tool which can help me to learn relationships easily. I mean which can draw relationship instead of me figuring out by hit and try.?
I want to export this database to Microsoft SQL Server. So I want to learn whole database schema to learn tables logic.
Thanks
Is this just a set of VFP free tables or is there a VFP database, as well? If there's a database, you'll have files with DBC, DCT and DCX extensions. If you have those, open the database and take a look:
OPEN DATABASE whatever
MODIFY DATABASE
If there are relationships defined between the tables, you'll see them there.
VFP ships with a program called GENDBC that will generate code to recreate a database. Since it's all SQL code, that might help you to see what's in there, as well.
The Stonefield Database Toolkit is designed to work with Visual FoxPro and has a lot of documenting ability. Not free though.
Related
I just installed and imported my database in Visual Studio , All I want to see is schema to get a quick relation of among different tables , I was hoping if I could get a way to do the same in SQL server just like it can be done with my sql reverse engineering
I use Azure data studio (the extension is buggy ), I also have Sql server manangement studio , I also visual studio and selected database management pack where SSDT was included and now I simply imported the database which I want schema for
SSMS has some rudimentary diagram tools to pull in objects and see any relations that exist. Something to watch for is that if you add any relations or modify anything other than the layout on that diagram, you actually change the database itself.
There are some free/cheap ERD apps/sites that you may want to investigate and many will give you a script to run in SQL Server to extract the schema in a format they can use.
I'd recommend searching on ERD apps that can do database diagrams, but for a free option you may want to check out https://dbschema.com/ (there's a free/trial version) or https://dbdiagram.io as they can handle some simple ER diagrams. (note - no affiliation to either, just some examples/options)
You can't easily forward-engineer changes with it, but it can work to just see the relationships visually. If you're going to use ER diagrams regularly, a paid option will be much more helpful. There are a lot of options available, but for that sort of design work you probably want collaboration and the ability to push out changes to a live database from the ERD.
I am relatively new to sql server and we are using sql server 2014 version in my workplace. Why do we actually need this database diagram in sql server(using SSMS)?
A database diagram offers a visualization of the database structure, and that's it's best (and some will probably say only) advantage.
While it is possible to use the diagram to edit the tables, including renaming, adding / removing columns, setting keys and what not, These things are usually best handled using DDL code (of course, if you know what you are doing).
You can think of a database diagram as a WYSIWYG editor for the database schema, and just like most (if not all) WYSIWYG editors, it does have it's drawbacks.
That's correct for all SSMS designer windows.
In fact, every DBA I know claims that the SSMS designer windows should never be used for designing database objects, and one must always prefer using DDL directly. I can only say I completely agree with this statement.
How do I copy the structure only (i.e., empty, no user data) of all tables, views, and indices from one SQL-Server database to new (empty) database?
(If anyone remembers dBase, this was done with "copy struct" for each table. I know also that this could be done by reverse-engineering the structure of the database into SQL statements using a tool like ERWin, but I don't have that either.)
I'm working in a very bureaucratic (maybe even paranoid) client site, in which I can only create temp tables, and only read from the regular tables. But it's really important that I be able to insert and update in a "safe" area.
You can generate scripts to generate a cloned test area for your database Documenting and Scripting Databases
Microsoft's SQL Server supports this scenario through partially abstract tools that can work with the database model, visualize it, edit it, transfer the model from one place to another and even compute differences between models and this way create database schema upgrade script.
The part that I have memorized is that those models are stored in big XML files called *.dacpac and there is a schema compare button available if I open *.sqlproj project in Visual Studio
This is whole architectural concept, more abstract and different from dBase, and you can start learning more about it e.g. at
Microsoft SQL Server - Data-tier applications
(Or try Google: "dacpac deployment")
My DBA just lost some development work that he did on our development database. Poor fella. So naturally our manager asked him, at our status meeting, how this could happen and how we could avoid this happening in the future. "Source control could alleviate the problem" I suggested... The dba's response; "No, we just backup the server more often". Now I would like to help my DBA understand what source control is and how it fits together with a database schema and development on that schema.
Previously I've tried to explain him that there's nothing special about the source code behind tables and stored procedures and it should be in a source control system (TFS in this case). But he just didn't bite. Now, while this misap is in recent memory, I would like to take another stab at it.
So my question is, do you know of any good advice I could pass on to my DBA and maybe even a couple of resources explaining how you would go about migrating a DB schema to be under source control and find its proper place in the build and deployment processes?
A couple of facts about the environment:
Source Control on a TFS 2008 Server.
Database is a MS SQL server 2008 with >300 tables and >300 other objects (sprocs, triggers, functions etc.).
Clarification:
We have been using DB Ghost and other change management solutions on other projects with other DBAs, in the past. We even have the license for VS DB edition! The problem is getting the DBA to even think about this way of developing for the database. He's really old school (i.e. migrating changes manually from environment to environment), and unfortunately hes the only one who knows anything about this particular DB.
See how to version control sql server databases and Do you source control your databases, among many others. Or use the search page. Basically, your approach seems correct. Good luck persuading the DBA...
If you are using Visual Studio Team System, I recommend having a stab at their Database Edition (i think these days it comes with the Developer Edition if you are an MSDN Subscriber). What this will allow you to do is to script out all your schema, stored procs, views, triggers, etc and source control these. This should also make the dba more comfortable since he will be working with a "Database" version of the tool rather than the "Developer" version (naming can go a great lengths with people). As you make changes from Visual Studio, you can manage script changes as you work, and source control them.
If your company has an MSDN license, they can use the Visual Studio Database edition. There's a video tutorial of it here.
I have no power of purchase, so I don't know what the cost breakdowns are. But it has the capability of source controlling all the parts of a DB schema, and includes creating change-scripts as well as auto-deploying straight from VS if you want (I wouldn't recommend that).
In general though, it's pretty solid as a database source control option.
Source control for databases can be quite contentious. It's different to use source control for something that produces a binary because you can't lock the source: a stored proc is a row in a table and there is not single table to read to get a table definition.
Also, version to version is mostly a set of ALTER statements. You script out CREATEs and add them to source control. This makes it harder to use in cases like this.
To me, this is more a procedural error.
Why was the change not done from a script? Forget where the script lives, but why no reproducable and re-runnable script? Perhaps linked to the change tracking number? If the database is reset (loaded from prod) then how would the change have been re-applied to prepare for production. And other questions.
I believe in source control and we use it: but it has limits for database work.
First you are approaching this incorrectly. If the dba won't bite on Source Control and he is making errors that affect the system, the person you need to persuade is his boss.
If it helps, I'm from the old school too and I love having our database objects in source control. How nice to be able to revert one table without having to restore the whole database backup to a different location and then move the table. How much faster and simpler. How nice to be able to compare two different versions and see what changed. How nice to deploy a change and know exactly which database changes (say, for instance only twelve of the 23 possible ones) go with the part you are deploying and not some other unfinished project. How nice to know exactly which scripts were involved in a particular change you had to rollback. How nice that nobody is making on-the-fly changes on production since we now require all production changes to be from source control scripts. There are so many fewer errors and issues to worry about.
Yes it was a change in how we did business, but we did it through a policy change from on high so three was no argument and the dbas went through a couple of times and reverted any objects different from source control to the source control version, so now nobody will even think of doing a database change without it being in source control.
As the product manager for SQL Compare I've spoken to many 'traditional' DBAs who are uncomfortable with third party tools mainly because they have a system that works for them and sometimes changing can be difficult. There are many situations where I am convinced that they would benefit from our tools if only they gave them a chance. Frustrating.
One thing you might consider trying is Red Gate's upcoming tool, SQL Source Control. This is designed to build source control into SSMS, in other words it doesn't require DBAs to leave the comfort zone of their management environment. The bad news is that the tool hasn't been released yet. The good news is that we have an Early Access Program. Please visit the following link to find out more about the tool:
http://www.red-gate.com/Products/SQL_Source_Control/index.htm
you can't really put a large database under source control, so your DBA is right.
what you can do practically is to put your schema under source control, and maybe a few smallish 'configuration' tables.
One way to source control database is to store the data in and about the database separately
You can have the all the tables, procedures and function scripts as SQL files and add them to source control.
Export the database data as insert statements into SQL files, each with a fixed size. This is a cumbersome process as it would involve a lot of files that are to be tracked and controlled.
I am not sure if the VSS/SVN are able to read and keep history of changes to dump files created by the database backup options.
Its not clear from you question if you want to protect the data in the Db or the schemas in the Db. If the latter then you could identify all the important schemas and run an cron job that pulls the schema definitions from the Db and inserts them automatically into a source control system (perhaps even via triggers on the schemas??).
But this still just amounts to backing the system up more often. For what you envision you would need source control integrated with the Db tools and I don't know of any product that does that.
(and I shudder to think of VSS integrated into SQL management studio :-(( )
My answer to this same problem was to export all DB objects to text form (more than 136,000 of them) and then create the SourceSafe projects to hold them. Any New or changed objects in the DB now go to the SourceSafe structure, while unchanged are left alone.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I've recently inherited the job of maintaining a database that wasn't designed very well and the designers aren't available to ask any questions. And I have a couple more coming my way in the near future.
It's been tough trying to figure out the relationships between the tables without any kind of visual aid or database diagram.
I was wondering what tools are recommended for this. I know about Visio, but I was hoping there were some good open source/freeware applications out there. I don't need it to change the database at all. Just read it and create some kind of visual aid to help me understand how things are laid out and try to figure out what the designer was thinking about how the data should relate.
Additional answer data: SchemaSpy was the kind of thing I was looking for, but having not done a lot with the command line in ages, I opted to use SchemaSpyGUI. There was also some configuration to get used to since I don't work with Java much, but the end result was what I was looking for (on open-source replacement for Visio's ER diagrams).
Try SchemaSpy. I ran it against a rather complex database and I was quite pleased by the result, with advice on optimization.
Try DBVis - download at http://www.minq.se/products/dbvis/ - there is a pro version (not needed) and a open version that should suffice.
All you have to do is to get the right JDBC - database driver, the tool shows tables and references orthogonal, hirarchical, in a circle ;-) etc. just by pressing one single button. Enjoy!
What DBMS (Database Management System) are you using? Many modern DBMS's like SQL server and Access can create an E-R diagram for you.
Microsoft Visio is an excellent tool and can reverse engineer SQL from any datasource.
DDT (Database Design Tool) can reverse engineer from raw SQL on windows and is very lightweight (very small free download).
MySQL Workbench is one of the more popular MySQL tools and has a freely downloadable version.
SQLFairy can do the same for MySQL on Linux.
dbdesc is not free, but I've heard very good things about it. It works with several of the major databases out there.
I have been lucky in that I haven't had to decipher other people's database schemas yet. I have use a set of templates that come with CodeSmith.
Firstly, may I say that I feel your pain!
Here are a couple of my tips:
In general, a tool will only be helpful if the designers have correctly defined all the primary and foreign keys, so be aware that a tool might not pick up all the important relationships.
The most useful thing is to see what queries are being performed by the client code. This will tell you not only what relationships exist, but which tables and relationships are the most frequently used - that's where you'll want to concentrate your effort.
There is a bit of open-source software out there but Visio Professional's tool for reverse-engineering database schemas is quite good because it de-couples the process of reverse-engineering and diagramming. I use this a lot because it tends to be readily available at most sites.
One nice feature of visio is that you can reverse engineer and then construct your own diagrams from the reverse-engineered schema. Doing this is a very good way to explore the schema and understand it as you are doing this work as a part of interactively building a reference document for the schema. I've used this technique to reverse engineer everything from Activity Based Costing Systems to Insurance Underwriting Systems, typically without much help from the vendor. Tinkering about with Visio diagrams is quite relaxing.
Between this and a little hypothesis testing about FK relationships (If the FK is not physically present on the table) you can make sense of quite complex schemas. I've found this diagramming approach makes Visio a head-and-shoulders leader because you can easily interact with the reverse-engineered model in a fairly convenient way. You can fill in missing foreign keys, build subject area diagrams and add annotations on the diagrams. The interactivity of this process makes it a good learning tool.
This is a somewhat subjective view but the interactivity works very well as a learning proces for me and it's by far my preferred approach. Most sites won't begrudge you the £300 or so for a license - if they don't already have it available. The only site I ever worked where they had to get it in was because they had Visio Standard instead of Pro. I asked nicely and the PHB signed it off.
I use mysql workbench (http://www.mysql.com/products/workbench/) for mysql databases. You can attach the workbench to your database and it will draw the ER digram for you.
Using pgsql/win32 I found the easiest solution was to write a perl script that made use of Graph::Easy from CPAN. Query the database for foreign key relationships, make a directed graph with tables as nodes and FK relationships as links. If this is your setup, I can post the code.
I like to try and see if the applications that use the database have ways of logging the SQL they use (or the DB backend itself, but that tends to be less tractable). Getting a feel for what requests performed on the database helps you concentrate on the important tables.
As with most things, the 80/20 rule applies here: 20% of the tables will do 80% of the interesting stuff. Once you've figured them out, a diagram is rarely necessary.
Look at the primary key foreign key relationshsips that have been set up as a starting place.
Since a database without existing diagrams, may not have relationships set up formally, I look at the table structures and names and make my best guesses as to what might be related to what, then dig into the structures to see if there are obvious (but undefined) foreign keys. I look at the stored procs to get an idea as to how the tables are joined and what fields are being queried on.
While automated tools to figure out the database can be spiffy, I find that when I really dig into the details of the database myself, I end up with a much better understanding than I can get from any picture created automatically.
I have some pretty good experience with Aqua Data Studio for reverse engineering a DB schema. It is very feature rich and supports even more exotic databases like Informix or Sybase.
This helped me with generating the ER diagrams on MS SQL Server 2012:
MS SQL Server management Studio > File menu > "Connect Object Explorer"
Choose your Database node and expand it. under this node you'll find a sub-node called "Database Diagrams"
Right click on "Database Diagrams" > "New Database Diagram" > Add tables that you wish to see their columns, relationships, ...
Use Visio. If using Vision 2010, you will need to use the Generic OLEDB Provider for SQL Server to ensure that there will be no problems with connecting to the Visio Driver.