I have an MS Access frontend which is using a SQL database as backend. To connect, I use a ODBC connection and have created the needed entries in "ODBC Data Sources (32 Bit)"
When I will give the database to others, they will need to create this data source. I have a batch file for this so they can just run it.
If they do not run it, they will get a fault like "ODBC connection to XY failed". How could I change this error or at least write a second Message Box afterwards where I can tell them "run the Batch file XY to connect"?
When I will give the database to others, they will need to create this data source.
that is your first bad mistake and assumption. You MOST certainly do NOT want to deploy your applcation that way.
The way you deploy?
You take your accDB file, and link the tables to sql server. And you link using what is called DSN-less connections. Such connections do NOT require ANY data source to be setup on each work station.
So, ok, now you linked the tables to sql server (the production one - you probably were developing local on your developer PC and using a local copy of sql server express edition.
So, so now you link the tables to THEIR server, and then you now compile the accDB down to compiled executable version of Access - a accDE.
You are now free to deploy this "application" to any and all workstations for that company - and they do not have to re-link tables, do not have to setup a data source, and in fact they don't have to do anything, but simply run/launch the applcation.
How to make and get a dns-less connection?
Well, the MOST simple way is to ALWAYS, but ALWAYS ALWAYS create the linked tables using a FILE dsn. In fact, when you launch the ODBC connection manager from Access, the default is to use a FILE dsn. Never, and do not use "system" or "user" dsn.
If you link the tables using that FILE dsn, then Access converts them to DNS-less connections. At that point, you can even delete the DSN you created - access 100% ignores the DSN, and you don't need it anymore.
Next up:
If you been using nc 17 or nc 11-18 drivers? then yes, each workstation MUST have that same driver installed. Or, you can use the older "legacy" sql driver. But be careful - the legacy driver does not support datetime2 columns data types.
So, MAKE double, triple, quadrible sure that you not using data types and columns that require the newer drivers.
Right now, for some of the larger sites, we STILL use the older "legacy" driver, since that driver is installed at the OS level, and has been installed on every copy of windows going back to windows xp - in fact windows 98SE edition started shipping that driver. So you can 100% assume that the legacy sql driver is and will be installed on each workstation.
And by using + adopting dns-less connections, then no setup of the connection on each workstation is required. As long as those work stations are on the same network to sql server when YOU linked the tables, then they are good to go.
Now, on some sites, we actually can't even be on site, and we can't even pre-link to their sql server. So, what we do is on applcation startup, we check the current link for a linked table, and if it does not match a little external text file we ALSO included when setting up the work station, then we use VBA code to re-link the tables on startup. But once again, re-link of tables in VBA is easy, and again does NOT require ANY KIND of "dsn" or odbc setup on each work station.
And in fact, another way we used to do this is have a table in the front end, and it had one record, and that record had the connection string. So, right before deployment, we just edit that one record table in the front end to have the correct connection to their sql server. And once again, on startup , we check a linked table, and see if the connection strings match, if they don't, then we run the VBA re-link code, and once again, zero configuration and zero need exists to setup anything at all on each work station.
So, as a general rule, every dog, frog, insect that deployed access applications? We setup some re-link code and check that link on startup. In fact most developers have done this even without sql server - and even when using a access back end, then re-link code is included to resolve this issue.
but, be it linking to a access back end, or sql server back end? Some time of link check and system is assumed to have been cooked up by you, and this code will run on startup to check if the linked tables are pointing to the correct location.
But, be the back end oracle, sql server or whatever? You can create what is called dsn-less linked tables. As noted, you can use VBA to do this, or in fact you can use the linked table manager ---- as LONG AS you use a FILE dsn when you linked, then access coverts that to dns-less for you, and you be good to go.
so, in effect, you don't have to test/check/know for a odbc fail, since you checked the correct connection string on startup.
However, there is a way to trap, and check for a odbc failure, and this involves using a DIFFERENT way to connect, since we all know that if you have a odbc fail, you are duck soup (you have to exit Access, and there is NO KNOWN way around this issue - (well, except for testing if you can connect, and you do NOT use a linked table - since as noted once a odbc connect error triggers, it is game over.
The way you do this "alternate" test is like this:
Function TestLogin(strCon As String) As Boolean
On Error GoTo TestError
Dim dbs As DAO.Database
Dim qdf As DAO.QueryDef
Set dbs = CurrentDb()
Set qdf = dbs.CreateQueryDef("")
qdf.connect = strCon
qdf.ReturnsRecords = False
'Any VALID SQL statement that runs on server will work below.
' this does assume user has enough rights to query built in
' system tables
qdf.sql = "SELECT 1 "
qdf.Execute
TestLogin = True
Exit Function
TestError:
TestLogin = False
Exit Function
End Function
So, above does not hit or use a linked table. And a HUGE bonus of above? Once you execute that above valid logon, then any and all linked tables will work - AND WILL WORK without even having included the user/password in that connection string for the linked table. This is in have a huge bonus in terms of security, since now you don't have to include the user/password in the linked tables which of course exposes the user/password in plane text for all users that could look and see and find the sql user/password used.
In fact, what this means is that you can link your tables, but NOT include the user/password when you link the tables!!! - this is a HUGE security hole plugged and fixed when you do this.
So, once a valid logon has occurred (such as above), then any and all linked tables will now work, and work without even having included the user/passwords in those linked table connection strings.
As noted, the other big bonus is that you can use the above code to test for a valid connection, and avoid that dreaded "odbc" error, since as noted, if a odbc connection error is EVER triggered at any point in time, you MUST exit the applcation - no other way out.
However, it should be noted, that if you ever are going to use a wi-fi connection, or say cloud based sql server say running on Azure?
In that case, often with wi-fi, or a cloud based edition of sql server, then of course such connections over the internet are prone to minor and frequent dis-connects.
ODBC was developed long before the internet, and long before people would do things like connect access to some cloud based sql server running, and using a connection over the internet. But, if this turns out to be your use case, and deployment case?
Then you have to bite the bullet and ASSUME and ENSURE that you now adopt the nc 11-18 drivers. (I would go with nc17). These new drivers are now "internet" aware, and they are able to gracefully handle minor dis-conects, and in fact automatic re-cover and re-connect.
So, if you are ever going to use wi-fi, or connect to cloud based server? Then yes, you have to link the tables using say nc17 newer drivers, and you ALSO MUST THEN ensure that the same driver version you linked tables with is to be installed on each work station. You still don't have to setup any dsn connection and all that jazz - but you do have to ensure that the driver you used is ALSO installed on those work stations.
As noted, for larger deployments, we thus use the standard "legacy" sql driver, as it would be too painful to go to all work stations and install this driver.
However, we had one location, and for months they were experience in odbc connection failure. We had them replace a router, and even a network card on a server - but the problem still remained.
We suspect that some workstations had aggressive power management turned on, newer windows 10-11 will often put the network card to sleep, and thus when using access, we were seeing odbc errors. So, for that company, we had them install nc17, and linked access to sql server using that driver, and the problem went away (because those newer drivers now have built in re-connect ability - this is a relative new feature of ODBC, and one that legacy systems and drivers don't have.
we are using SSIS 2016 and with parameterize connections. Every time we open the solution the connection manager is trying to connect with the credentials available in the project.param , due to unavailability of the password and repeated trying the db user account is getting locked.
Looking for some inputs if there is any settings we could change for connection manager not to try to connect when the solution is opened.
Thanks for your time on this.
RR
If you change the project setting to work in Offline mode, you should be able to open the project without validation checks firing which should alleviate the ever-so-fun lockout policy. That might be a user solution file setting so each team member might need to set it.
A different approach is to leave the design time user value to a non existent account. The run-time will swap in the properly parameterized connection but any developer opening the packages won't lock anyone out.
When I first started using plsql developer, it would allow each window to have a separate connection to a different database.
At the time I found that annoying, so I turned it off.
But now I need to compare objects across databases - ie : how is the view on dev4 different than the same view on dev5.
I can't find the setting / preference I changed.
Help.
Ok the quick answer to this is Configure -> Preferences -> Connection ( under Oracle grouping) -> uncheck/check 'Allow Multiple Connections'.
With this checked, you have an option at the bottom of every SQL window to choose a separate connection to a database ( a downward facing triangle). You ALSO have the 'Connect as Main' option when you right click on a db connection, which will connect all subsequent SQL windows to that db.
With this unchecked, the 'Connect' option goes away - leaving you with only 'Connect as Main', and the option at the bottom of each SQL window goes away.
FYI
I'm helping our SA migrate a reporting service instance to a new server and we're encountering a strange issue. She installed SSRS 2005 and restored the reporting services databases without any issues. She then restore the encryption key from the previous server without a problem.
But when we try to open report manager, it goes to the URL of our previous SSRS instance instead of the new one (i.e. when going to https://[new URL]/reports, it takes us to https://[old URL]/reports/pages/folder.aspx). The only way we can get to the current reporting service instance is by specifying the entire URL (i.e. https://[new URL]/reports/pages/folder.aspx). Also, when hovering over the links at the top (i.e. Home, Site Settings, etc), the hyperlinks also point to the old URL. I imagine this doesn't have anything to do with the database we restored, so we're wondering if this has something to do with the encryption key from the old server.
Sorry if this isn't clear, but any input is appreciated.
Okay, this is going back in time but we had the exact same problem. Testing my memory, I believe the server name is stored in the Keys table in the ReportServer database in the column MachineName. That will be your old server name.
Take a backup!
Change it to your new server name.
Restart the Reporting Services service.
I am using Access2000 and Developer Tools, JRO for internet synch, RepMan 4, and was using Win Server 2003 (dedicated server). Just upgraded to Win Server 2008 and have been trying to get Internet synch operational, but with no luck. Here's my problem: I see that MS is urging/forcing subscriptions to SharePoint2010 for internet synchs, however I am not sure that their new platform is as useful to me as their old. Each company I distribute to will run a runtime version of my access application at multiple locations(could be 1 location per company, could be 100). They need to be able to direct synch within each location via LAN (anywhere from 2 to 20 computers). They do not always have an Internet connection (they are at sea), and when they do, it's by satellite and transmission costs are high. And so occasionally they will connect with one computer and perform Internet Replication to send data to home office(could be daily, weekly, or monthly). My current means of synching via JRO is very simple. After attaining an Internet connection, just open a form and either click the synch LAN button or the synch Internet button. Also, by not utilizing automatic synchs, we avoid corrupting other replicas when one is bad or a user has deleted massive amounts of data inadvertently (since deletes always win).
I feel that eventually I will have to update to Access2010 just to keep abreast on new developments in MS (i.e. new .PDF reports instead of .SNP). I recently purchased Office 2010 Pro in order to begin looking into this, but of course this will take some time to work thru.
Here are my questions:
Will SharePoint2010 allow for only one subscription per remote location to handle synchronization back to main office, or would every replica that performs a direct synch at the remote office be required to maintain a Sharepoint2010 subscription?
Can I still use JRO to complete direct synchs among replicas at a remote location and within the home office, and therefore only use Sharepoint 2010 to pass those updates via Internet to the home office.
Will Sharepoint 2010 Enterprise allow me to host multiple company databases in one central account (similar to RepMan4), or must I set up a separate account for each of my customers? If so, do I need to purchase a copy of Sharepoint 2010 for each of these customers?
Will Sharepoint 2010 handle basic data replication and/or design updates in a similar manner to my current set-up? Will I be able to utilize my custom conflict manager?
Also- do you have any info whether Internet synchronizations are indeed capable utilizing Access2000 viaIIS 7.5 on Windows Server 2008 with RepMan4? I have not found anyone who has accomplished this – latest suggestion is that maybe IIS needs to be run in a 32-bit environment in order to open the synchronizer, but I have not yet tried this.
My company makes a product called [EQL OnWeb - link deleted] which is designed for exactly your use case. It works with getting Access 2000 databases on the web without rewriting them first, and there's a free trial so you can see if you like it.
I won't comment in detail on SharePoint 2010 because clearly I'm biased... but I like our product better :)