Is this possible?
We have a Configuration Management Database that stores information such as our servers, what datacentre they're stored in, applications that reside on them, as well as interfaces that send data from one application to another.
We would like to use Visio to connect to our SQL 2005 database, and automatically generate a flow diagram that details these dependancies and relationships.
So again - is this possible? If so, does anyone know of some documentation that details how to do this?
Is this what you are looking out for?
Related
I am currently creating a vb.net program in which users upload a song file to the program and then it is saved within the programs files. I have set up the actual saving of the files but would also like to store some meta data of each in a SQL database within my program.
I have looked online and although i now understand the basics of SQL, im still a little fuzzy on how you actually implement this within VB.net. I have already added the library- Imports System.Data.SqlClient but failed to work out how to begin coding in SQL.
The basics of what im trying to acheive is a if statement that will determine wether or not a SQL database has been created in a specific location, and if it hasnt it should create it.
All constructive answers appreciated, thanks.
There are a number of different database engines available. The namespace that you have chosen contains the ADO.NET client classes for Microsoft SQL Server. You would use a connection string to specify how to connect to the database. This would often contain connection information, such as server name, user name, password etc, but it sounds like you want to store data locally.
There is a local version of SQL Server called LocalDB, but I think you would still need quite a lot of the SQL Server components installed for that to work. Although you can package these with your application they may be too large for you, so you may want to look at SQL Server Compact Edition, which is much smaller and allows you to package the whole engine as part of your application and is useful for storing data locally. Compact edition doesn't have quite all of the features that LocalDB does, so you may want to compare the features available for each.
Although you can use the ADO.NET objects to connect to a database, I think most people these days would use a layer on top which transfers data back and forwards between objects in memory and the database. This also allows you to use Linq to query the database in most cases. I personally use Entity Framework. You might want to look into that. There are different ways of configuring EF so you may want to look at a tutorial. Once you have it set up, you will probably find it much easier and safer to work with than writing SQL manually though.
I am working on a project having a large scale database with several stored procedures and I need to use the data in SharePoint 2013, the database is in SQL Server 2008 R2
According to my understanding I have two options:
1) is to create a Web service, using entity framework to interact with the database and most probably will use WebAPI. My logic will be in Stored procedures or DAL layer.
2) Secondly, I did a little research and got to know about the Business connectivity services provided by the SharePoint 2010/2013 as I am working with 2013 so I will be using visual studio 2012. Now learning more about the BCS I understood that I can map each table as a content type and then somehow define relationship. Anwyay, implementing BCS is a separate issue which I think I will somehow manage.
My question is how am I going to import/include my stored procedures? and if not stored procedures then where will I write my queries to get the data from the BCS?
Please direct me to right direction. Thank you.
Using a custom BCS connector you implement the way you want to retrieve the data from the DB (directly in C#), so you can query directly the table, or stored procedures.
If you want to try a BCS connector to create an external content type to use in SharePoint, take a look at my blog. My example is related to indexing sql data for the search, but the way it's done in SharePoint is creating an external content type, and this content type is the one that you index. So you'll find useful information on how to create that BCS connector.
What concepts/steps shall i need to learn to access a central database(server). The system will have a software(manipulate by users) which access the database in the server. System like inventory systems, billing, etc..
First of all you need to know vb/C#.net (which I assume you know). Next you must be able to write SQL queries, stored procs, T-sql, etc. to communicate to the database. Finally you need to know ADO.net to communicate between your application and database.
You can start your ADO.net study from here:
http://msdn.microsoft.com/en-us/library/e80y5yhx.aspx
http://www.codeguru.com/vb/gen/vb_database/adonet/article.php/c15033
Here is a link which will help you under stand the data access layer: http://msdn.microsoft.com/en-us/library/aa581778.aspx
Hope this helps...!!!
Is there a way to show table relationships as can be done in Access? Consider two tables:
Services
serviceid
application id
Application
application id
application name
I have already set up the diagram.
When opening the table service id I want to see the related application details like in Access.
Is this possible?
First of all, you an always use access to connect to SQL Server and see relationships through it.
The built in database diagram feature will also show relationships, as you describe. You can find it under the database in question in the diagrams node.
Here is an article about different options to produce an ERD.
Update:
In order to see results, I would suggest using access to connect to SQL Server, as described in the link above.
The SQL Server GUI does not have this facility, and if you want to see results from several tables you need to write the SQL queries that will generate the wanted data.
You could also create a VIEW:
CREATE VIEW ServicesApplication AS
SELECT S.ServiceID, S.ApplicationID, A.ApplicationName
FROM Services AS S
LEFT JOIN Applications AS A
ON S.ApplicationID = A.ApplicationID
That way you can always access the coupled data easily by manipulating the ServicesApplication view instead of the separate tables.
SQL 2008 doesn't have anything built in to provide that functionality. Almost sounds like you're looking to trouble shoot an application by looking at database entries...if thats true I'd recommend learning tsql well enough to write these statements as you need and not rely on another application to provide a visual interface. heh, if I'm completely wrong with that, ignore me :)
If you still want the 3rd party application route...I beleive TOAD has that functionality within it, though I've never connected it to a MS SQL 2008 server before. There are other third party applications out there that will provide this functionality, though I imagine they aren't all free. If you're looking for a free solution and already have Access going, Oded probably has the best idea here...connect MS access to the SQL 2008 server (linked tables) and use MS access to provide the features you want from ms access :)
Without going into specifics...I have a large SQL Server 2005 database with umpteen stored-procedures.
I have multiple applications from WinForm apps to WebServices all of which use this DB.
My simple objective now is to create a meta-database...a prospective data-dictionary where I can maintain details of which specific app. file uses which SP.
For example, My application Alpha which has a file Beta.aspx...uses 3 SPs which are physically configured for usage in BetaDAL.cs
You might have inferred by now,it will make life easier for me later when there is a migration or deprecation....where I can just query this DB SP-wise to get all Apps/Files that use the DB or vice-versa.
I can establish this as a single de-normalized table..or structure it in a better way.
Does some schema already exist for this purpose?
SQL Server supports what are called extended properties, basically a key-value dictionary attached to every object in the catalog. You can add whatever custom information about the catalog (comments on tables, columns, stored procedures, ...) you wish to store as extended properties and query them along with the normal catalog views.
Here's one overview (written for SQL Server 2005, but roughly the same techniques should apply for 2000 or 2008).