As a .NET Desktop developer, I have a lot of experience working with various databases that are already up and running; but I'm not a DBA. I'm currently working at a company where I am ther only software guy here to build them software from scratch -- their previous enterprise-level solution was an Access database with macros and a couple forms built it. So, I basically have no one else to go to.
With that preface, how the heck do I get a database -- ANY DATABASE!!! -- added to my VS solution? I've been beating my head against this for almost 6 hours and have made zero headway. At this point, I'm ready to say, "Screw MS databases!" and start looking at MySQL or PostgreSQL or something.
The desktop application I'm developing has to work whether there is an internet connection or not, so I need a local database that installs with ClickOnce. From what I've found so far:
SQL Server [Express] 2016+ requires Windows 8 or later (a non-starter since 95% our customers are still running Windows 7)
SQL Server Compact is being deprecated and won't work past VS2013
I think LocalDB is what replaces Compact in 2016+ (?)
Okay, so I started with this tutorial:https: //learn.microsoft.com/en-us/visualstudio/data-tools/create-a-sql-database-by-using-a-designer However, trying to add a "Service-based Database" just gives me this error once: "The 'DBProviderFactories' section can only appear once per config file." I try again and get this error repeatedly: "Unable to find DbProviderFactory for type System.Data.SqlClientConnection" I've Googled both errors and all the answers that I've been able to find pertain to VS2010 or earlier and their solutions are either not applicable or don't work.
Next, I tried this tutorial: https://msdn.microsoft.com/en-us/library/aa983322.aspx I've tried adding new data connections through the "Server Explorer" panel. I don't see "[*] Compact" as an option. When I try "Microsoft SQL Server Database File", I just get the error: Unable to find the requested .Net Framework Data Provider. It may not be installed."
I've even tried adding data sources through the "Data Sources" panel; that doesn't work either.
I've installed the "Data storage and development" addon from the Visual Studio Installer, several versions of SQL Server 2014, SQL Server Compact 4.0, and maybe a few other executables from Microsoft's website.
Nothing works.
Help...
I think I just found it!
Evidently, there are "machine.config" files on your computer. Search for them all, and make sure that there is only a single tag for "DbProviderFactories". I can add a database object now. Hopefully, this puts me in business...
https://social.msdn.microsoft.com/Forums/vstudio/en-US/7b4f353b-77fd-427c-976b-5968abc88c13/visual-studio-2010-unable-to-find-the-requested-net-framework-data-provider-for-sql?forum=vseditor
If what you are saying is that you are writing a browser based application - then one would migrate the tables to SQL Server (Express) or even MySQL - it really doesn't matter. Then write a new web app. The existing Access app would serve as a model for seeing features & screen layout but is otherwise not portable.
On the other hand, if you are re-writing a Windows application; then the decision is whether the payload requires a server solution or if one can stay at the PC level. If the payload is suitable for PC then a re-write using either Visual Studio or Access again.
Access is a front end db - the tables in the back end whether they be stored in SQL Server or an Access file are entirely passive. All the processing is done by the user's PC. If the payload allows that then this is the lowest cost re-write option.
If you've outgrown a PC level payload - then one must develop a back end database feature set with a more passive front end.
This is the biggest problem I've had with my project so far. Every time I try to publish it, I get hangups and crashes whenever the project tries to access a database file (which is fairly often).
I have two database objects, both created as part of my Visual Studio project under the main solution, as BUILDERDATA.mdf and CHARACTERS.mdf. When I access them during test builds, everything functions just fine. However, they always fail in the published project.
I get the feeling either they're not exporting correctly, or the act of publishing the project is breaking the connection strings, so I'm hoping someone can help me pinpoint the issue.
Under my project settings, I have a connection set up to each database. They're both Connection Strings, their scope is Application, and the value is this:
Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\BUILDERDATA.mdf;Integrated Security=True;Connect Timeout=30
Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\CHARACTERS.mdf;Integrated Security=True;Connect Timeout=30
Under Project Properties -> Publish -> Application Files, both databases and their log files are set to Data File (Auto) for Publish Status, Required for Download Group, and Include for Hash.
Under my Prerequisites, I have SQL Server 2012 Express LocalDB marked, as well as Microsoft .NET Framework 4. Part of my code uses .NET, so that's required anyway, and I included SQL Server Express so it can access the database files. However, 2012 is the newest version available for me to include, so I'm not sure if there's an issue with that version?
If there's anything else you guys would need to see, please let me know. I just want to get this figured out and fixed so I can have my friends start testing my program. :(
I created a new database called "staj" and imported 3 excel files into it. I edited the column names and arranged the primary keys. After that, I opened a new web form in Visual Studio and added my database to the project using Entity Framework. It was all fine until I created a new table called UserList and tried to use it in Visual Studio, it says it could not be found. I tried to update Visual Studio by going to Tools -> SQL Server -> New Schema Comparison.
I then got stuck because I can't get past the "Choose Source" part even though I clicked new connection and connected to my SQL Database and tested it. It said it was fine but, I simply couldn't find how to see the changes I've made to SQL in Visual Studio. Refreshing or active syncing didn't work. How can I do this?
This whole time I've been choosing the wrong keywords. My answer lies here -> How to: Update an .edmx File when the Database Changes (Entity Data Model Tools)
I have a server that is capable of creating and running an Excel Import task using the Import Wizard. I am trying to automate that process by using a visual Studio 2010 Integration Services package, that I am developing on that server.
The problem happens when trying to design the package. I have added an excel connection and pointed it at the Excel file on a local disk (the same file I have already successfully imported using the import wizard). When I add an Excel Source to the DataFlow and specify the excel connection, when I go to the Name Of the Excel Sheet Drop down I just see "No tables or views can be loaded" and get the following error.
"Could not retrieve the table information for the connection manager.
Failed to connect to the source using the connection manager ..."
I can't find this error logged anywhere and i don't know why it is failing. The directory is shared to Authenticated users and the file is not in use.
Any ideas how to debug this error? I understand there can be issues running this in 64 bit mode, but does that apply to development?
I should add that it is an excel 2007 file .XLSX and the connection is set to Excel 2007.
2019-11-08 The answer by GavB841 below looks promising, if anyone tries it and it works please let me know. (I am no longer working in this area.)
It seems like the 32-bit version of Excel was not installed. Remember
that SSDT is a 32-bit IDE. Therefore, when data is access from SSDT
the 32-bit data providers are used. When running the package outside
of SSDT it runs in 64-bit mode (not always, but mostly) and uses the
64-bit data providers.
Always keep in mind that if you want to run your package in 64-bit
(which you should aim for) you will need both the 32-bit data
providers (for development in SSDT) as well as the 64-bit data
providers (for executing the package in production).
I downloaded the 32-bit access drivers from:
Microsoft Access Database Engine 2010 Redistributable.
After installation, I could see the worksheets
Source:
Extracting Data From Excel with SSIS
The workaround is, I save the excel file as excel 97-2003 then it works fine
I also ran into this problem today, but found a different solution from using Excel 97-2003. According to Maderia, the problem is SSDT (SQL Server Data Tools) is a 32bit application and can only use 32bit providers; but you likely have the 64bit ACE OLE DB provider installed. You could play around with trying to install the 32bit provider, but you can't have both the 64 & 32 version installed at the same time. The solution Maderia suggested (and I found worked for me) was to set the DelayValidation = TRUE on the tasks where I'm importing/exporting the Excel 2007 file.
The recommendations from this article Extracting Data From Excel with SSIS resolved the issue for me.
I downloaded MS Access Database Engine 2010 32 bit driver
from the link in that article.
Also set Project Configuration Properties for Debugging Run64BitRuntime = False
In SQL Server 2014 SSMS (Integration Service Catalog -> SSISDB -> Environments -> Projects for all Packages in Validate checked box 32 bit Runtime.
My SSIS packages are working now in both VS 2013 and SQL Server 2014 environments.
Simple workaround is to open the file and simply press save button in Excel (no need to change the format). once saved in excel it will start to work and you should be able to see its sheets in the DFT.
You need to use an older version of the data connectivity driver (2007 Office System Driver: Data Connectivity Components) and select Excel version 2007-2010 in the connection manager configuration window.
I assume the newest data connectivity driver for Office 2016 is corrupt
Here's the solution that works fine for me.
I just Saved the Excel file as an Excel 97-2003 Version.
As discussed in the below:
Solution:
Go to https://marketplace.visualstudio.com/items?itemName=ProBITools.MicrosoftAnalysisServicesModelingProjects and install the latest version, it has a fix in there to resolve this issue.
Reference: https://developercommunity.visualstudio.com/content/problem/745991/could-not-load-file-or-assembly-microsoftdatawareh.html
A fix for this issue has been internally implemented and is being prepared for release. We’ll update you once it becomes available for download. For now, please install latest SSAS from https://marketplace.visualstudio.com/items?itemName=ProBITools.MicrosoftAnalysisServicesModelingProjects to work around the issue. Sorry for any inconvenience.
I faced the same issue. I think #Rishit answer helped me.
This issue is related to 32 bit/ 64 bit version of driver. I was trying to read .xlsx files to SQL Server tables using SSIS
My machine was pre-installed with Office 2016 64 bit on Win 10 machine along
with MS Access
I was able to read excel 97-2003 (.xls) files using ssis, but unable
to connect .xlsx files
My requirement was to read .xlsx files
Installed AccessDatabaseEngine_X64 to read xlsx, that given me
the following error:
I uninstalled the AccessDatabaseEngine_X64 and installed
AccessDatabaseEngine 32 bit, that resolved the issue
My answer is very similar to the one from #biscoop, but I am going to elaborate a bit as it may apply to the question or to other people.
I had a .xls that was an extraction from one of our webapps. The Excel connection would not work (error message: "no tables or views could be loaded"). As a side note, when opening the file, there would be a warning stating that the file was from an online source and that the content needed activation.
I tried to save the same file as an .xlsx and it worked.
I tried to save the same file with another name as an .xls and it worked too.
So as a last test I only opened the source .xls file, clicking save and the connection worked.
Short answer: just try and see if opening the file and saving does the trick.
Solution
Actually, if you are using SSIS in VS2019 then a problem could occur so do the below things:
Go to the excel sheet and save it again in .xls format.
Once you will use it in .xls format, automatically type will be coming as Microsoft Excel 97-2003 worksheet.
Like in the attached picture.
You will be able to load your sheet data.
I found that my excel file that was created in Excel 365 was incompatible with any of the versions available. I re-saved the excel file in 97-2003 version and of course chose that version in the dropdown list and it read the file OK.
you can try this:
Uninstall office365
then install only Access Database Engine 2016 Redistributable 64 bit
Also set Project Configuration Properties for Debugging Run64BitRuntime = False
It should work.
After researching everywhere finally i have found out temporary solution. Because i have try all the solution installing access drivers but still i am facing same issues.
For excel source,
Before this step you need to change the setting. Save excel file as 2010 format.xlsx
Also set Project Configuration Properties for Debugging Run64BitRuntime = False
Drag and drop the excel source
Double click on the excel source and connect excel. Any way you will get an same error no table or view cannot load....
Click ok
Right click on excel source, click on show advanced edit.
In that click on component properties.
You can see openrowset. In that right side you need to enter you excel sheet name example: if in excel sheet1 then you need to enter sheet1$. I.e end with dollar symbol. And click ok.
Now you can do other works connecting to destination.
I am using visual studio 2017, sql server 2017, office 2016, and Microsoft access database 2010 engine 32bit. Os windows 10 64 bit.
This is temporary solution. Because many peoples are searching for this type of question. Finally I figured out and this solution is not available in any of the website.
I have a VB based VS2005 appl developed using Access DB a few years back on Windows XP and it has been working fine until moving to Windows 7. I re-built the solution by changing to the x64 platform also at the sametime modified the Access DB a bit resulting in a new Access DB file to be included in the solution. When I debug in VS2005, I have the new version of DB residing in my project\x86\Release folder and successfully access this new version.
Problem is that once I create the solution for deployment, the deployed application kept on opening the OLD version of the access database (mdb) file. I was not able to find where is it opening the old version of DB from even after I removed the mdb from the installed folder. I have been a lot of digging and research on web and not able to find out how to solve this problem.
Can someone please help to tell me how I can have my deployed appl to open the new version of DB ?
Thanks in advance
It sounds like you are not allowing for virtualisation - do you know about this? For security reasons after XP (Vista onwards) Microsoft doesn't allow writing to the Programs folder and if it encounters an application attempting to do this makes a copy of the files trying to be written to (in your case an Access database) and places it somewhere (can't remember exactly where at the moment) hidden from casual user.
For example, if you look at the database on your Win 7 machine in the same location at your .exe file I should think you will find it is unused - and since it was installed on the machine the OS has been redirecting requests to read/write to your database to the virtualised copy it created for you.
So, first of all find this other copy (sorry I'm currently on a mac and can't remember the location) and see if that contains data that your application is creating. Then try substituting your new database (making a a copy of your old one first of course) and seeing if your application is reading/writing to it OK.
Then it is a matter of handling replacement of databases during application installation.
However, you should give serious consideration to placing your database in a location which is not virtualised!