I have an SQL database and want to connect to it using VBA in order to support some legacy functionality. I'm using an ADODB connection and need to know what my database DSN is. How can I find this?
I'm using SQL Server 2008, thanks! :D
A DSN (data source name) is an indirect way of referring to the database. You have to create them manually (or semi-automatically using a wizard of some kind). Go to ControlPanel->AdministrativeTools->DataSources (ODBC) to see if one has already been defined for the database to which you want to connect.
But I think you might mean "connection string", not "DSN". There are many, many ways to tell ADODB how to find and connect to your database (DSNs are just one of those), but you always need a connection string.
I have often turned to ConnectionStrings.com to help me through the maze of similar-but-not-identical options.
There may not be a DSN. DSNs are not created automatically.
I'm not sure you really mean DSN, as a DSN is an ODBC concept. Still, look in Administrative Tools->Data Sources (ODBC).
Related
Using the following:
MS Access 2016, Office 365
SQL Server 2012
I have 100+ SQL Server tables and views linked into an Access database via ODBC connection. All of these SQL Server objects are from two SQL Server databases that reside on the same server. All of these connections have been set up using the Access user interface and re-linked via the Linked Table Manager.
I've been experiencing a number of Access database issues lately, so I’m combing through everything with a fine-tooth comb. I noticed that the connection strings for all my SQL Server objects have a number of inconsistencies (see below). There does not seem to be any pattern in terms of when these objects where created and the format of the connection string either.
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database1;Network=DBMSSOCN
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;
ODBC;DSN=Database1;Description=Database1;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database1
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2010;DATABASE=Database2
ODBC;DSN=Database2;Description=Database2;Trusted_Connection=Yes;APP=Microsoft Office 2016;DATABASE=Database2
Is it problematic that there are so many variations of the connection string? I've done some research (i.e., Googling), but I don’t much experience in this area of databases. Some connections have a "Network" specified, but others don’t. Per connectionstrings.com (https://www.connectionstrings.com/define-sql-server-network-protocol/), “Network=DBMSSOC” specifies a Winsock TCP/IP connection, which I believe is the appropriate choice for my network setup. Is it problematic that this parameter is excluded from several of the connection strings?
I would most certainly “harmonize” all of the linked tables to the same connection.
You can use the linked table manager to do this, but likely code is better.
You need to select all tables in the linked table manager, and MAKE sure you click on prompt for new location. This will force you to create (or select) an existing DSN. In fact, I would select all tables from the “one” given database, and then click on the “always” prompt for new location. When you do this, then all will posies the SAME link and connection string.
There are good number of reasons, one good reason is Access will cache the connection for you. So if you have “different” connections for the same database, you will have multiple caches of those connections. This likely will not affect performance “much”, but it still a good idea.
And if you are NOT using a trusted connection, then your connection strings in fact do NOT need to include the uid/password. (However, the cache of the uid/password requires exact string matches (minus the uid/password). In this approach, you can execute a “one time” logon on application start up, and then all linked tables (without the uid/password) will now work. However, you using trusted connections here, so this tip + issue don’t matter.
In your example, you using trusted connections, so issues are “much” less of a worry or problem.
I also STRONG suggest that when you launch the ODBC manager from Access, that you ALWAYS but ALWAYS use a FILE dsn. The reason for this is that then Access will convert the connections to DSN-less for you.
This means that you can now deploy the front end application to any workstation, and you don’t need to setup or have any DSN connection copied, or even setup on the workstation.
So I would in fact select all of the tables for one given database, (check the prompt for new location), and then create a FILE dsn (they are the default anyway). Once you link, then do the same for all the other tables that point to the other database. Again re-link.
The result will be a dsn-less connection, and thus your application will work on any workstation on the network, and do so without having to setup a dsn of any kind on each workstation.
So yes, you don’t have to, but it seems over time, some tables were linked using a different DSN, they should be harmonized. And if you ever introduce some automatic linking code, you want to be able to distinguish between the two databases, and you code will have a rather difficult time doing this with a “hodge” podge of differing connections.
So you can use the linked table manger to harmonizing the connections – just ensure you select all tables from a single given database, and then re-link with a FILE dsn, the result will be a DSN less connection (access will ONLY use the DSN during the linking process – after that, access don’t care, nor does it use or even look at the DSN, or even if it exists.
Having said all of the above, it not clear if this issue is related to your errors, or instabilities in your application. (a good idea is to always distribute a compiled version of your application - (a accDE as opposed to accDB).
I understand that this is painfully generic and broad. Nonetheless, all the answers on wikipedia and yahoo (none here that I can find) are pretty useless.
I know T-SQL, C#, etc to some degree. I understand the idea of a database. However, I have NO idea what I created when I made a "server" on my computer through Msft SQL Server. Now I can make databases on that server, and I can connect to them with Visual Studio (sometimes) to use with LINQ or "raw" calls.
Please help me understand (or direct me to an article) of what this myComputerName\SQLEXPRESS (SQL Server xx.x.xxx) thing is. I assume the databases are stored locally...somewhere. SQL Server provides access to the DB files? Why can't they be accessed directly?
Thank you if you even read all this. I really can't narrow the question down.
I guess one specific question is "Can I access the databases without SQL Server running?" Where do I even get the connection string?
You are asking multiple questions, here.
However, I have NO idea what I created when I made a "server" on my
computer through Msft SQL Server. Now I can make databases on that
server, and I can connect to them with Visual Studio (sometimes) to
use with LINQ or "raw" calls.
Please help me understand (or direct me to an article) of what this
myComputerName\SQLEXPRESS (SQL Server xx.x.xxx) thing is.
The layout of a database server is as follows:
Server
Instance a
database aa
database ab
...
Instance b
database ba
database bb
...
...
So, when you install MS SQL Server, you install a MS SQL Server "instance". In this "instance", you can create a number databases. Each database has database files, the exact location of these depends on the settings you chose during installation.
I guess one specific question is "Can I access the databases without
SQL Server running?"
You do not usually open dbf(mdf -ldf) files (the database data files) without MS SQL Server, why would you want to ? You should use the backup/restore features inside MS SQL Server.
Where do I even get the connection string?
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring%28v=vs.110%29.aspx
The "server" is a process/service running on your computer which can be connected to over the network and provides the API to access your database.
"Why can't they be accessed directly?" Is like asking why do I need Word to view Word files, can't I use Notepad for that. Sure you can, but not really.
Another reason is - imagine multiple processes need to access the database. If each reads and writes to the same files, something WILL break if they don't coordinate. Having a separate server process encapsulates all this.
"Can I access the databases without SQL server running?" I mean yes but actually no.
If you want a database that your program accesses directly (or let's say, your program is also the database server in a sense) - then you can use sqlite, or for simple tasks there are also ODBC drivers for CSV, so you can use CSV files as if they were a database. A dedicated SQL server is always better for bigger more complex tasks and data models though.
I've created a new database using Microsoft SQL Server Management Studio, and now I want to interact with it through LabVIEW. I already have several VIs to interact with a previous database, using the database connectivity tool kit. This database was created by someone who has since left the project and I can't find it in anything but LabVIEW.
I'm quite experienced with LabVIEW, but completely new to and bewildered by databases.
Thank you in advance.
The first Connectivity Toolkit VI called should be Open Connection.
The existing code (VI) will either use a file or a string as an input.
If the input is a string, then you will need to create a new connection string compatible with your server. You can find common SQL Server strings at https://www.connectionstrings.com/sql-server-2008/
If the input is a file name, you can copy the .UDL file that is referenced and then modify the copied file by opening it (double click) and then select the OLE DB Provider for SQL Server and then set the connection options to point to your server, database etc. and then test the connection.
Basically the workflow you have to go through is the following:
Open connection
Execute your query
Fetch data (if needed)
Close connection
If you search for "Database" in the NI Example Finder shipped with Labview you will find a few good starting points.
In particular give a look to Database Connection.vi and Database Fetching.vi.
If you plan to use transactions try also Database Transaction.vi.
I found that the solution to my problem was to create a .udl file and use that as the file path for opening the database connection.
Here's the address that taught me how to do this:
http://msdn.microsoft.com/en-us/library/e38h511e(v=vs.71).aspx
Thank you to everyone who submitted answers, they certainly helped point me in the right direction.
UPDATE: If anyone knows a tool that is free, and would display, and let me edit DB2 table data stored on a Zos System, I welcome that as an answer too. Really all I'm trying to do is find a nice windows GUI interface to avoid using the 3270 environment.
I'm connecting to a DB2 database with Oracle SQL developer.
There's several tables in the database, but I don't see them listed when I start the connection, or make a query.
I'm using a DB2 on zOS
and I've got the connection with the following 2 drivers
db2jcc.jar
db2jcc_license_cisuz.jar
Does anyone know if this is something I have to live with, or is there something I am missing to show all the tables? Also, if people know why I can't edit in-line query results, that'd be awesome to. They seem to be read only.
FYI, schema browser doesn't allow me to do anything either.
At work we use DbVisualizer. Your mainframe DBA's will need to give your account you are connecting with privileges to see the system catalogs.
DBVIS
Alright so I want to convert an already exist SQL Server database (2005) to a MYSQL database.
There is nothing extraordinary to be done
The only things I need to achieve is
Recreate the tables
Transfer data
Relationships would be nice but not necessary
No views, no sprocs, no functions.
Any easy way to do this.
Also do you know of any Free DST (Database Synchronization Tool)
which would let me do
MSSQL to MYSQL
MYSQL to MYSQL
MSSQL to MSSQL (I know there is SQL Delta for this - not free though)
have you looked at pentaho's kettle (or pentaho data integration)? http://kettle.pentaho.org/
we use it to copy over and keep in-synch disparate database systems, such as mssql<->mysql, which seems to be what you are asking for.
kettle is even more powerful than that, allowing you to query ldap databases, straight text files, etc...
its diagramming tool is similar in look and feel to microsoft's dts (but more powerful, imho)
[DBConvert] is best place to solve your Query.
Download links are:-
http://dbconvert.com/convert-mssql-to-mysql-sync.php?DB=6
Download and Install DBConvert on your computer
After installation you may convert your database from MS SQ L To MY SQL in very easy way...
select source for remote connection enter IP of the server
and check connection.
Here you see your source connection is conneted
Same for the destination create connection.
Select table you want to convert in your destination database.
After complete the copying process click exit to terminate process.
Here your database converted...
Also you may get discount on the product checl the link...
http://dbconvert.com/gift.php
Have you checked out these tools?
http://dev.mysql.com/tech-resources/articles/migrating-from-microsoft.html
Make sure to set the correct SQL Mode in MySQL, the MSSQL setting sounds good to me. With this setting, MySQL works pretty well with ANSI SQL, T-SQL looks like ANSI so you will be fine.