SQL Server Migration Assistant for access hangs after selecting MS Access database, it just shows 0% and nothing happens. Up to this point, everything worked fine, but after I configured encrypted connections on the server with a TLS certificate, for some reason starts to hang at 0%. At the same time, SQL Server Management Studio connects over an encrypted connection without issues and no other issues were[enter image description here noticed anymore.
Perhaps this information will help someone. I was able to solve my issue in the following way. I uninstall SSMA first, then uninstall Microsoft Access Database Engine 2016 Redistributable. Rebooted the machine, downloaded it again, and installed first SSMA then Microsoft Access Database Engine 2016 Redistributable.
BTW, what I reported earlier was on a Windows 10 machine. Just tried on a Windows Server box and did not run into any problem. That Windows Server box had the most recent defender patch, a slightly different version of course. Version 1.343.352.0
Related
What we know / I've tried so far:
It failed during installation. Everything else seems to be installed correctly except for "Database Engine Services" (Ignoring server replication).
The installer sent me here, but this solution doesn't seem to work either.
The SQL Server service doesn't start.
The following screenshot is what I see when I click on the repair:
Looking through the logs, this is the repair error description: The SQL Server feature 'SQL_Engine_Core_Inst' is not in a supported state for repair, as it was never successfully configured. Only features from successful installations can be repaired. To continue, remove the specified SQL Server feature.
Thank you!
I couldn't install SQL Server 2019 Developer as well because of other reason below:
A computer restart is required. Please restart your computer and try
the Basic installation again.
So, I restarted my Windows PC, then I could install SQL Server 2019 Developer.
In our company we have to support a large legacy system built on Microsoft Access 2010 as frontend and SQL Server 2008 R2 as backend. The backend SQL server runs on Windows Server 2008 R2. Currently our users works on Terminal Server sessions on a Windows Server 2008 R2. A couple of days ago we started to test Windows Server 2019 and Notebooks with the latest version of Windows 10. We recognized a big performance difference while executing the same Access databases on the different environments.
For instance the creation of a report takes 27 seconds (new environment) instead of 7 seconds (old environment). The database.accdb is identical, the backend is identical (still Windows 2008 R2 Server with SQL Server 2008 R2 and SP2), only the execution environment (Windows) changed.
Does anyone of you have an idea how to explain this?
In Access 2010 the SQL server tables are linked using System-DSN data sources. On the old environment ODBC is used (Driver: SQL Server, Version: 6.01.7601.17514).
On the new environment I tested the following drivers:
ODBC Driver 11 for SQL Server (2014.120.5543.11)
ODBC Driver 17 for SQL Server (2017.173.01.01)
SQL Server (10.00.17763.01)
SQL Server Native Client 10.0 (2009.100.4000.00)
SQL Server Native Client 11.0 (2011.110.5058.00)
I created a new System-DSN using the different drivers and updated the linked tables in Access. But in any case the performance is still bad. I also tested the latest version of Access which comes with Office 2019, but again it is slow.
Sounds like your terminal sessions are getting throttled. Despite the fact that you have a SQL Server back end, Access is still doing a fair bit of thunking with the result sets, so any resource throttling differences between your Server 2008 and Server 2019 policies could be choking Access in the new server.
I think your answer is going to be found in Windows System Resource Manager. The page says it's not being maintained, but following the "Recommended Version" link leads to a generic Server 2019 page. Here's another article about how WSRM might be throttling sessions: Using WSRM to control RDS Dynamic Fair Share Scheduling.
Compare the Weighted_Remote_Sessions policy in 2008 and 2019 servers. There's either been a change to the default settings or behavior or the 2008 server policy was modified in the past to get to the current performance level.
Ok, a number of things to check.
First thing to check:
Launch the ODBC manager and check if SQL log tracing is on. I don’t know why, but I see sql logging turned on.
You NEED to be 100% sure it is turned off.
You MUST launch the ODBC manager from the command line or start menu, since the one in the control panel is for the x64 bit version, and you are using Access x32 (I assume).
So launch this version:
c:\Windows\SysWOW64\odbcad32.exe
So VERY important to launch the x32. It is assumed you are using a FILE dsn. So check these two settings:
(Make sure they are un-checked).
Next up?
Link access using the IP address of the sql server.
So, place of say:
myServer\SQLEXPRESS
Use:
10.50.10.101\SQLEXPRESS
(Of course use the IP address of sql server, not the above “example” IP).
The above things are quite easy to check.
Still no performance fix?
Then disable the fire wall on your new Terminal server (I seen this REALLY cause havoc).
And, disable windows defender on the new TS server if running.
The above tips should fix your issues.
If above don’t work, then next would be to check the priority settings for the TS server (GUI over server).
However, I am betting the above checks should restore your performance.
I am working on a project where I will be provisioned a SQL Server 2017 database server. However, the only version of SQL Server Management Studio available to me is 2008R2. I could request a newer version but this may take 1-2 months before it is finally installed on my machine.
Am I going to run into compatibility issues? Are there any database settings in SQL Server 2017 I would need to set in order to use this?
I am pretty unfamiliar with the MS suite of database tools so sorry for my ignorance in this! Thanks
In response to comments:
I have a managed system so I am not able to install or run software that has not been "approved". I have tried the portable version of VS Code but that did not work for me. I am going through the process of requests SSMS 2017 but like I said in the question this will not be available for 1-2 months. In the meantime will SSMS 2008 work?
As unlikely as this may be, I happen to have two, and only two, versions of SSMS installed on my machine; 2008R2 and 2017. I'm in the midst of an upgrade project.
I opened SSMS 2008R2 and was to connect to and generally poke around on a SQL Server 2017 server and the related databases. I didn't do anything too complicated (a few SELECT statments & an UPDATE), but they worked. The objects I expected to be visible were visible. And I didn't have to do anything to make it work. It just worked.
Mostly.
Except that every time I right clicked on a table, an error box opened with this message:
Index was outside the bounds of the array. (Microsoft.SqlServer.Smo)
But if I hit the OK button, the box cleared and the desired right click menu opened and functioned. That will get irritating, but if you poke around in the Options menu, there might be a way to make it stop. I invested no minutes trying to do that.
At the very least, you should be able to work while you're waiting for your upgrade.
For what it's worth, I work for a government contractor and have the same level of security constraints you do, so I feel your pain.
Another approach is to run sqlcmd, which would have been installed with SQL Server 2008R2. I was able to connect from sqlcmd to a SQL Server 2017 Docker container (external/internal ports 1433). I did not encounter any errors/warnings when creating a database and table, and running some light queries.
Interestingly, I was unable to connect to the same server using SSMS 2008R2. Perhaps the protocol used or the security required (e.g., TLS 1.2) for the underlying connection was different. Clearly it works based on Eric Brandt's results.
here is my setup:
Sql server 2008 standard running on Vista - VMware running a XP machine with VS2008 inside it.
If I open a SQL database in my host computer in sql server management studio and make structure changes to the database and then go back to visual studio, my visual studio has lost connectin to the database (says a network error has occured) - refreshing does not work. Closing down VS and reopending fixes the problem.
Has anybody else noticed this or is there maybe something wrong in my setup I should be looking into?
I can query the database, add data, delete data with no issues - only if I change the structure such as relationships or add remove columns etc.
Thanks,
Joe
I don't know if your problem is the same as mine, but if it is you could probably fix it by resetting some settings in Visual Studio.
This might be a server faults question.
I had a similar issue with network sharing / SQL security in VMware (though mine was fusion on OS/X.) The issue seems to be the network drops and loses connections. In my case I was always able to resolve the issues with dhcp release / renew on the client.
I raised a support call with VMWare on it; the basic response was check your vmware is patched up-to-date and then make sure you have the right version of the vmware tools installed on the client. When that didn't work they had me change to full dhcp on the virtual machine and the host rather than fixed IP addresses.
I'd recommend NOT Attaching DB's as a file, but Attaching them to your local machine using SQL Server management studio express. You can use the following connectionstring:
connectionString="Data Source=(local)\sqlexpress;Initial Catalog=dbname;Integrated Security=SSPI;"
This will allow you to use the database from Visual Studio as well as in SQL Management studio....
edit the connectionstring is for SQL Express, you'd have to change it if you're running SQL Server 2008 (I believe change the Data Source to your machinename/ip)
I have two issues both related to (I believe) my SQL Server setup. I have installed SQL Server (the full thing) from MSDN downloads of the x64 version on my Vista 64 Home Premium box. After running into multiple issues I finally got it working. This is a new box so I ported over a database that I need to work on from another server. That also worked fine. My first issue however came when I tried to open a database in SQL Server Management Studio:
"Unable to find the requested .Net Framework Data Provider. It may not be installed. (System.Data)"
The box itself isn't new and definitely has .NET installed (version 3 I believe). I found that someone posted this as a bug but as the team (SQL Server team) could not reproduce it, they removed it. I've tried installing the recommended SP3 patch to no avail. It's only when I try to open a table for viewing the data (right-click and "Open Table"). I can even execute queries and retrieve results (from inside management studio). I'll follow pretty much any suggestion to try and get this working.
My second issue is that I cannot connect to the server. I thought I could just work around it (with queries), but I did not find that it added any ODBC connections on the box, just the drivers. Management Studio can access the DB just fine, but the machine itself doesn't appear to recognize that anything is running on it, at least on the default port (1433) and no, I do not have a named instance. When trying to manually add the server to the DSN or any datasources it cannot find the SQL server (under Control Panel > Administrative Tools > Data Sources (ODBC). Under SQL Server Management Studio it appears as a registered database server (I think this is because it connects on port 1434 from what I hear? not sure). This is my primary problem, and even if I can't open the tables (the first issue) I absolutely NEED to be able to set it up so that I can connect to it. The language source I am connecting from is ColdFusion which is set up as a stand-alone server (IIS not installed, not using it right now).
As for connecting to it, make sure all the services are running. SQL Server Agent in particular.
Also, check in the SQL Server 2005 Surface Area configuration for Services and Connections. Check under "Remote Connections" to see if "local and remote" connections are on. It might be set to "local only".
CF versions 6+ do not use the OS's ODBC connections. They use JDBC over IP to connect. You need to make sure you have allowed TCP/IP connections to the DB using the SQL Server Configuration Studio. Then, use the Data Sources page in the CF Administrator page (usually localhost:port/cfide/administrator, replacing "port" with the port you're using for the CF built-in server).
Why though, would it default to this
and why would this be an issue with my
own machine (local testing)?
SQL Server 2005 is meant to be more secure by default, so not all the protocols are opened up by default.
Sql Server Agent doesn't have anything
to do with remote connections, but I
seemed to recall there being an issue
with doing discovery on the network if
the Agent wasn't started
Maybe you're thinking of the SQL Browser with named instances.
Did you try this process?
http://oakleafblog.blogspot.com/2007/03/orcas-march-ctp-on-vista-database.html