I've been struggling very hard to make this work. I'm using a software that uses paradox database, which I never used.
My problem is: I can open the program in multiple machines on the same time, but i can't seem to connect via ODBC when there is a program open in any machine (a .lck file maybe?). When noone is using the program I can connect without problems...
I understand that the lock file is there to protect the database integrity, but i wish just to make select commands via SQL directly into it... Is there any way to do it? A read-only connection maybe?
Thanks for the help!!
I had the same problem and I am living with this work around solution on the implementations of software I do where I work.
To make it work:
On the server machine of the paradox database, you have to create a new partition with the same letter where you will map on the client machines;
Share the unit drive;
On the client machines, map a new drive to the shared drive (repeating: the letter must be the same than in the server machine);
Put the database files in this drive;
Create the ODBC paradox system data source (it must be the 32 bit wizard) using the new directory for both Folder and Network folder;
Delete the existing .NET and .LCK before testing;
test...
I've read something about setting AUTO ODBC to TRUE on BDE too...
Related
I am trying to find the best procedure to get data from our SQL server at headquarters to update apps running on local machines in various locations not connected to our network. Our current data and application is in Foxpro where you simply copied the data file, so I am not very familiar with using SQL databases.
The field app uses localdb and users don't save anything to the database. When the app opens it checks a web site to for updates. I tried detaching our HQ .mdf and .ldf, downloading it and overwriting it on the local machine, but localdb would not attach to the new file (same name). I thought localdb closes and detaches when the application closes , but maybe I am wrong. I also wonder if I need the log file since no changes are made and I dont need to rollback anything. I have searched for a good article on this topic but haven't found anything. This must be a fairly common scenario in many companies.
You want to look into using replication, probably snapshot replication. This allows you to distribute on whatever schedule is applicable to send one or more tables, or other objects, to off site sql server instances. You can use Http to send data.
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.
I'm new to ODBC and DSN's in general.
We have a product A that accesses a database "T" via a DSN D1 that has already been defined.
I'm now writing a test app testA that exercises various functionalities of product A and also needs to validate various database entries made by A.
For this, I am trying to access the same DSN D1 (that was setup for database T) to read from db and do the necessary validations.
I'm however having issues with that. I've setup the dsn, but when I do a SQLConnect with this dsn, I get a return value of -1.(I dont see any corresponding values for this return type either)n
Any clues on what this means and if I'm doing something wrong.Can we have 2 different processes or apps connect to the same DSN?
You can test access using a "udl" file. These files are largly misunderstood IMHO. They are simply a script that is used to launch the (db) connection library. You can create them by creating an empty file in notepad and changing the extension to .udl from .txt. You then double click on the file and configuer access to your database. (they launch a build in configeration applet). In my experience if a .udl file connects then any application will connect or 100% there is a problem with the application. If the udl file will not connect, then 100% there is a firewall or something probibiting access to the account being used to try to connect.
I have a windows application written in VB.net. After finishing it I'll setup the program in more than one pc. I want to connect the program in all PCs to one database in another PC using Microsoft Access, and I also want to limit the level of access of the users to the database in my program.
How can I do it? Many thanks.
Access is capable of handling multiple users, however once you get over 3 or 4 concurrent users you will start to notice that MS Access doesn't scale well. Access is designed for the professional but not an enterprise.
Microsoft SQL Server (Express edition is free - upto 4GB space) is designed for a large number of concurrent users.
I also want to limit the level of access of the users to the database in my program.
You can use folder Permissions if you wish to restrict access to the file. Personally in my old VB6 apps that used MS Access I called the file db.resources rather than db.mdb. This is because a.resources file cant be downloaded if it is hosted online (ref DotNetNuke) and also so people dont know which program to open the file in.
If you need role based security you need a enterprise level database such as SQL Server.
I want to connect the program in all PCs to one database in another PC using Microsoft Access.
Here is how you can have two computers share the same database.
a. Choose the main PC that will host the database
b. Host the database in a folder that is shared to the other users
c. Physically go over to the PC that isn't hosting the database, create a text fileon the desktop.
d. Rename the file extension from .txt to .udl and press enter
e. Double clcik the udl file and enter these settings and navigate to the shared folder that hosts the shared database:
f. Once the Test Connection is successful, close the Data Link Properties window.
g. Right click the UDL file on the desktop and choose Open With and open with notepad
h. You will see your connection string:
[oledb] ; Everything after this line is an OLE DB initstring
Provider=Microsoft.ACE.OLEDB.12.0;Data
Source=\\PCName\c$\temp\Database1.accdb;Persist Security Info=False
i. Set the second pc to use the networked connection string.
Access is perfectly capable to handle 2 users connecting to the same database. However this is not the main strenght of Ms-Access. So, if you plan to grow the user base it's better to start from the beginning with SqlServer Express (or MySql).
You don't need to use asp-net for this scenario if the user are on the same local network.
You are only required to prepare a valid connection string to identify the network location where you install the database. Of course, the PC hosting the database should share the network location and give read/write permissions to all users requiring the access to the database. (This could be the most complicated part depending on where you share the database)
I need to connect and send/receive information from an MS SQL server in my Lotus Notes app using #formula in realtime (I can connect using an agent, but I need to use inline code for this).
The commands themselves seem pretty straight forward, but setting up the configurations seems to be a topic with scarce documentation. Apparently I need to install an ODBC driver. Where would I find that, and do I install that onto the server or onto the workstations that will run this app?
If any Lotus gurus could step me through setting this up, it would be greatly appreciated.
Thanks
You'll need to install the ODBC driver on the workstations that run this app, if the users will be triggering the ODBC connections. If at all possible, I highly suggest setting this up on the server side, and having it run via an agent. That'll save you from a few headaches, including having to maintain the ODBC connections on each workstation and worrying if each workstation has access to the data and server.
You first just want to make sure your ODBC setup is correct. You'll need the appropriate driver, of course, and the connection information. This site has a walkthrough to give you an idea of how to setup an ODBC database connection
If you have MS Access you can use it to test querying from the ODBC data source. Once you've tested the connection works, you'll just refer to the data source name (DSN) in your #DbColumn, #DbLookup, or #DbCommand formulas.
Back to my suggestion on setting this up on the server side, that would mean you'd keep a copy of the data you're querying within the Notes database itself, and then users would be interacting with read-only data in Notes. You could schedule updates regularly on the server side of that read-only data and effectively create a cache of the data in your Notes environment. Then that data would replicate around to other replicas of the database, but remove the trouble of the ODBC connection being needed everywhere.
If you need realtime data, though, that solution is out the window and you'll have to go with a local solution. In that case, you might want to look at the LCConnection class or using an ADODB.Connection from script, as both will allow you to create DSN-less connections to data sources. You'd then save the trouble of requiring ODBC data sources on each workstation, and only have to worry about whether they can access the server from their workstation.
I would add another option to Ken's list. It involves having the server do the queries of the external database (therefore you are only setting up ODBC in on the server - you don't have to deal with it on the workstations). You create an agent that is launched on the server using the 'run on server' technique. When the workstation needs to query the external data, the code creates a throw-away document in the database, puts the query criteria into the temporary document, saves the document, then calls the 'run on server' agent passing a reference to the temporary document. The server launches the agent, reads the criteria from the temporary document, does the query, and writes the results back to the temporary document. Then the workstation can access the query results from the temporary document. A scheduled agent can delete the temp docs on a regular basis.
It sounds complicated, and it all has to be done in script, but I've done this in many applications and it is fast, flexible, easy to administer, and gives your applications a lot of power. Note that end users must have the ACL rights to create a document in the db (the temp doc) in order for this to work.
Good luck!