Click here to Skip to main content
15,887,027 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
Greetings,

I have a database that I have generated in SQL Express 2014 (its version right now is 12.0.2000.8).

However, I have noticed that when adding it to Visual Studio 2017 as a local copy (to make it server independent), the version is altered and updated. The reason for this, to my understanding, is that Visual Studio has SQL Local Database tools and packages from 2016, not 2014, so it versions the file (I checked this by grabbing the .mdf from the solution directory after it was integrated into the application and uploading it back to SQL Server. It gives read error because it is a higher version).

This means that in the deployment, even if the user installs the SQL Express LocalDB 2014 and .NET Framework 4 packages (I use this .NET to try to make the application compatible with Windows XP), the application cannot access the database and crashes.

This situation is further confirmed by the fact that, in previous attempts, it happened to me that the laptop where the application was developed was able to open the deployed application and when switching computers, it did not. This, which I did not understand at the time, was due to the fact that my computer does have the necessary packages to be able to read.

What I have tried:

So, I have deleted all SQL packages that are later than 2014 and I have also deleted all traces in Visual Studio 2017. And here comes the problem, because when I try to add again the .mdf to the project I find that I can not do it if I do not install the same extensions that generated the problem.

In conclusion, I would need a way (I understand that this is a compatibility issue) to close the version of the database, so that it can be read and written, but that its version is not altered in any way. I imagine it is possible, but I have no idea how to do it. I could also use, if possible, Visual Studio 2017 to allow me to add the database using tools that do not alter the original.

Many thanks to anyone who can give me a hand with this issue.

Best regards
Posted
Updated 2-Jul-23 23:50pm
Comments
RedDk 1-Jul-23 14:28pm    
Have you tried creating a database using the instance rig provided by the version of SQL Server you're running and then importing the off-color data(base) AS the data for that newly created instance? There are other things I'd try also.
Member 15627495 3-Jul-23 3:38am    
the package you need have to be included in the App Resources, to be downloaded, or could be part of your whole installer.

one remark about "express" edition, you won't be on a complete Db system. ( it's 'light' stuff )

1 solution

You can try and copy files manually, we had an instance beforw with different files and the following seemed to work for us, in your case the following might help -

Visual Studio's SQL Server Local Database tools and packages are designed to work with specific versions of SQL Server, and it wants to upgrade the database file during the import process -

1) Make a backup of your SQL Express 2014 database to be safe.

2) In SQL Server Management Studio (SSMS) or SQL Server Object Explorer in Visual Studio, detach the database from the SQL Server instance. This will remove the database from SQL Server but keep the .mdf and .ldf files intact.

3) Locate your .mdf and .ldf files of your database (normally found in your SQL Server data directory) and copy them to your Visual Studio project directory.

4) In Visual Studio, go to your Solution Explorer, right-click on your project, and select 'Add'- 'Existing Item'. Go to your .mdf and .ldf files you copied and add them to your project.

5) Once your files are added to your project, select the .mdf file in the Solution Explorer and open it's properties. Set the 'Copy to Output Directory' property to 'Copy always' or 'Copy if newer' to ensure that the files are included in your build output.

Keep in mind that you will need to manually manage and deploy your database file along with your app, as it won't be automatically attached to a SQL Server instance.

Seeing that you might need to deploy to Win XP, the above should suffice but where possible maybe consider to upgrade to newer versions to avoid headaches down the line.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900