I am struggling to make a SqlCE local database to work in my winforms project.
I`m used to work with web app, this is my first desktop app, and after understand a lot of tricks like when you insert data in your local database while debugging, the data goes to a magic database inside bin/debug folder - that I would never wonder by myself - and from yesterday to now, I launch my project again, and guess what the new trick? The database got lost ¬¬ !!
Suddenly my project can't recognize its own path to the database and it throws me an error: "The path is not from a legal form", I SWEAR I didn't move the mouse from yesterday when it was working from now.
Anyway, SqlCE gave me a lot of headaches already, I'm doing this project as a favor to a bookstore inside a charity house and I'd like this project gets only one weekend - it already didn't.
So, as I don`t have a big amount of data to store, what would be the alternatives to store this data without a .sdf file?
If you want to stay with SQL I would recommend SQLite. Small, lightweight and results are placed in a single file.
http://sqlite.org/
Related
I've just finished setting a dev environment where every developers /feature/, /bugfix/ and /hotfix/* git branches are automatically built and deployed to a freshly provisioned Windows Container which hosts the webapp and services creating a test environment, for each branch to be validated before merging into master.
While this is working quite nicely, I've still only got 1 dev db per developer which is used by all of their branches.
In an ideal world, I would like each of these test containers to use their own isolated db instance, however the db is currently at about 50gb at the smallest i can get it without going and tearing out historical data which is sometime useful.
What I would really like to do, is create a docker like image for this db and then spawn a new "container" from this image which only keeps track of the diff between it's changes an the original without ever altering the original db.
Is something like this even possible or does anyone have any ideas how I might achieve this db isolation, per container without having to create a full 50gb db for each?
Ok, So after much flailing around in the dark, I think I've finally come up with a solution. #ErikEJ, thanks, you started me off in the right direction. After looking into DB Snapshots on MSSQL, I found the only way to do writable snapshots seemed to be using vss and actually creating writable disk snapshots. This too led me down a long path of at first trying locally and failing, then trying to implement iscsi and still getting nowhere. Then I stumbled upon hyper-v snapshots and had a look at what was happening under the hood there and finally came across creating differencing VHD's. So basically my solution is as below.
Create VHD with a sanitised copy of my production DB mdf and ldf file in.
Then I create differencing vhds for each environment I need, mount the differencing vhds each in their own folder eg c:\db\Issue-1234 and create a new db DB_ISSUE-1234 by atatching to the files in these folders. Only the diffs are then stored and instead of having several 50-60gig copies of the db. I only have 1 and then the differencing vhds only store the difference.
I've just got this working with 2 or 3, so not sure how robust it is and how fast these differencing vhds are going to grow, but looking very promising so far and is allowing me to spin up multiple environments for testing purposes, extremely quickly (in fact all automated by scripts in deployment).
Hope this possibly helps someone else save some time one day and please let me know if anyone has figured out a more efficient/quicker/better way to do this :)
There is a legacy app that I have to make an edit to via VS, but I'm not sure what the process involves in recompiling the program. Since nothing else uses VS as it's just an app gluing together some things that support a legacy system, I rarely use it so I apologize for the unfamiliarity in how it works.
A while ago I lost everything on one side of my computer so I had to copy the app folder from the server that contains the entire app. As of right now I am in the .cs file where I need to update the connection string, because the database it connected to has been changed. Unfortunately anytime I make a change to these files I don't have the option to rebuild the whole app. Is this because the copy of the app folder is not recognized as a project locally? What must I do to make these changes and make sure they transfer back to the server?
I have an access database that has been used for many years, converted from Access 2000 to 2007 and was fine. In the last couple weeks it has been doing strange things!
There is a form for 'editing' a record. When the user clicked on the button to open this form, a small white box appeared and said 'Record Deleted'.
After that, the database was corrupted. I support this database and I can not even get into it in design view. When I try to open it (holding the shift key down while opening it), it takes a while, then it displays the Access design page that has the 'blank database' icon and to the right it lists the frequent opened databases.
So, I can't even get the to objects. The only option I had was to restore from a previous night backup. This meant the users lost all their work for the day. Today, one week later, it has happened again. All the users work was lost because I had to restore from backup.
I don't know where to begin to trouble shoot this since I can not get into it in design view when it has become corrupted. Looking for any suggestions to debug this. I can use a copy of the database I had restored.
Thanks
As a first and most important suggestion. You should split your database.You can do this from the database tools tab on top. By doing this you will have a seperate back end independat of the front end and your client will not loose any data as if they get the error / corrupted database it would not affect the data secured in the backend
Second I havent had the exact same error but in the past I have faced instances where the forms just dont work. a recommendation i read somewhere was to create a new blank form and copy over the elements from this form onto that and delete this form. I doubt if there is any problem with the VBA but it would be worth compiling the code to check.
Apologies if this does not help much, but I hope the first suggestions helps protect your client data in the instance your database crashes.
First, check if any automated VBA code or macro is running on OnOpen, OnLoad, OnCurrent, AfterUpdate, OnDirty, etc. events of the troubleshooting forms. Simply open the VBA window and look at code on the specific form's module. Or in the case of macros, open form in design view and check the Event tab of Property Sheet (and the same for specific buttons, textboxes, etc.). There may be DoCmd.RunCommands occurring when users interact with form controls.
Also, if you find yourself unable to open forms or deal with a corrupted database, consider beginning with a blank Access .accdb file and import all objects from the previous Access 2000 .mdb file. And if specific controls don't function properly, recreate them as needed.
As mentioned above, split your database between BackEnd (only tables) and FrontEnd (forms, queries, macros, modules) which prevents corruption, efficiently runs systems as only data is sent across the network and not whole application items, and overall fosters a better multi-user environment. Each user can have copies of the FE on their local machines but all will connect to one BE on a shared network. To help, Access 2007-2013 has a button for this on the Ribbon under Database Tools.
There is a process in our company built by a long-departed dev that pulls data from a cube stored in a MS SQL Analysis Server (which I typically access via Management Studio). The overall process almost never fails and is refreshed several times a day. However, there appear to be some bugs in the calculations that has been handed to me to investigate and fix.
Unfortunately, I knew nothing about cubes when this was handed to me, was not part of the original development process, and generic web tutorials don't seem to quite apply to whatever I'm looking at. On the plus side, trial and error has taught me enough that I can ask a few questions.
The bug is definitely in the calculations. But I obviously don't want to test in Production and I also don't want to make changes without a proper backup (that I know how to revert).
Is there a way to export the whole Analysis db to a .SLN file and open it in VS?
Should I instead use Script Cube as->Create to, change the cube name, and execute to make a copy?
If I'm later asked to add new dimensions or need to edit the data source, what's the best way to do this?
Any other tips?
You can create a Visual Studio project based on an existing cube. This will get everything in a project so you can investigate the calculations, make the necessary changes, deploy to a test environment, and check everything out before deploying to production. Don't forget to check the project into source control ;-)
I am in the process of writing an offline-capable smartclient that will have syncing capability back to the main backend when a connection can be made. As a side note, I considered the Microsoft Sync Framework but since I'm really only going one-way I didn't feel it would buy me enough to justify it.
The question I have is related to SQLite vs. SQLCE and ClickOnce deployments. I've dealt with SQLite before (impressive little tool) and I've dealt with ClickOnce, but never together. If I setup an installer for my app via ClickOnce, how do I ensure during upgrades the local database doesn't get wiped out? Is it possible to upgrade the database (table structure, etc. if necessary) as part of the installer? Or is it better to use SQLCE for something like this? I definitely don't want to go the route of installing SQL Express or anything as the overhead would be far too high for what I am doing.
I can't speak about SQLLite, having never deployed it, but I do have some info about SQLCE.
First, you don't have to deploy it as a prerequisite. You can just include the dll's in your project. You can check this article which explains how. This gives you finite control over what version is being used, and you don't have to deal with installing it per se.
Second, I don't recommend that you deploy the database as a data file and let ClickOnce manage it. When you change that file, ClickOnce will publish it again and put it in the data directory. Then it will take the previous one and put it in the \pre subfolder, and if you have no code to handle that, your user will lose his data. So if you open the database file to look at the table structure, you might be unpleasantly surprised to get a phone call from your user about the data being gone.
If you need to retain the data between updates, I recommend you move the database to the [LocalApplicationData] folder the first time the application runs, and reference it there. Then if you need to do any updates to the structure, you can do them programmatically and control when they happen. This article explains how to do this and why.
The other advantage to putting the data in LocalApplicationData is that if the user has a problem and has to uninstall and reinstall the application, his data is retained.
Regardless of the embedded database you choose your database file (.sqlite or .sdf) will be a part of your project so you will be able to use "Build Action" and "Copy to Output Directory" properties of that file to control what happens with the file during the install/update.
If you choose "Do not copy" it will not copy the database file and if you choose "Copy if newer" it will only copy if you have a new version of your database file.
You will need to experiment a little but by using these two properties you can have full control of how and when your database file is deployed/updated...