I'm working through the "Demo: Binding Data with the SqlDataSource" of this pluralsight video on ASP.NET Webforms.
All communication with the database works just fine, except it won't change when updates are made. The only thing I've done differently from the video is to use Northwind.sdf instead of Northwind.mdf. The database exists in the project directory, which is under my Users directory on win7 -- so it shouldn't be a permissions problem.
What could be preventing it from updating?
In case anyone wants to try the sample app, I uploaded the whole project folder here on mediafire.
Maybe you have two copies of the database. You are updating copy A and then checking copy B.
Or, it could be one of the reasons described here: http://weblogs.asp.net/stevewellens/archive/2009/10/16/why-sql-updates-fail-three-reasons.aspx
Related
I have lately re-discovered embedded databases such as Sqlite (sql, relational) and LiteDb (noSql) and I like working with them for small web apps or mobile apps.
However, I cannot find any good answer to where to place them. Where to put them if:
The web app is likely to be containerized
The database can grow dynamically
Changes to the code and new deployments should not risk losing any change in database
1. Database file as part of solution (versioned in source control)
I've seen places where the *.db file is placed somewhere in the solution and it's versioned in source control.
I can see how this could be a problem as the database can be modified outside the context of development (i.e: when the app is up and running in production, the DB may change and in the next deployment the db may be overwritten if no backup/restore process in place)
Sometimes I have seen it inside wwwroot/App_Data. See this for instance. I assume App_Data is some kind of protected folder and its files cannot be server statically by the web server (is it?). Otherwise this is even worse.
2. Database file in binary folder
When testing, it's fine to have the database file generated somewhere in the bin folder, but this causes a similar problem as the previous one. What happens when a new software version is released and therefore the database file is overwritten in production?
So the questions are:
Is there any good practice regarding where to place embedded database files?
Is there any alternative to having backup/restore processes to avoid the described data-loss scenarios?
What happens when the app is contenierized and the database file grows once deployed? If the file is inside a container along with the running application, can it grow indefinitely? I don't recall specifying anything about a maximum size for containers anywhere when creating images..
Is having the DB in an external storage such a cloud blob store the alternative? I'm guessing the real benefit of embedded databases is gone if the file is in a different host.
Any good read about this would be appreciated.
PS:
I am asking for AspNet Core apps mainly because I see some projects using the wwwroot folder to place the embedded DB, but the question applies to any technology/framework.
This other question doesn't help either.
I just started a new position replacing a developer who left abruptly working on a project that is based in the Kentico CMS. I am completely unfamiliar with ASP and Kentico, so the answer here needs to be tailored for a total beginner. I am familiar with other languages (PHP, Ruby, SQL, etc.) but have no idea where to begin with this.
So, want I am wanting to do is copy everything from our production site (db and all) to my local machine so I can develop on it easier. I have already exported the db into an SQL file, and copied all the files in our Kentico Instance folder into github, and cloned it on my local machine. I assume since Kentico is already "setup," going through the installation process in their documentation is not the way to go about this.
Any help would be incredibly appreciated!
David, basically there are a few "pieces" to running Kentico locally. Since, as you mentioned, Kentico is already set up, you should have an easier go of it.
A database with the necessary Kentico tables (it sound like you
already have this)
The codebase (all of the code files that you copied to github)
A valid license for any domain you want to run Kentico on. Was the site already public facing? Do you know what licenses you have
or can you log into the CMS Desk on the site that you copied
everything from?
Set up IIS for your local website. If you are unsure on this one I can explain further, but basically you need to add a new site,
point it to the root code folder for your site, and set the domain
to be a domain you have a Kentico license key for. You'll also need
to change the app pool settings to "integrated" mode (most likely)
and also set the appropriate version of .NET (if it's a recent
version of Kentico you'll want .NET 4.0)
Next you'll need to edit your hosts file to add the domain and point it to your localhost IP address. So add a line like "127.0.0.1
dev.yourdomain.com" or the equivalent.
Edit the web.config file so that your code can connect to your database. You will need to edit the connection string accordingly to
point to the database on your machine.
Once you have done these steps, your site should start to run just as it had before. I didn't give great detail on all of these pieces so let me know what problems you encounter so I can further clarify. More information about the current situation would also help.
One other note I would make: if you need the client to be able to review your work, it will most likely be more efficient and easier for you to leave the original database on the web server, and (if possible) connect to it remotely from your local machine. Since almost any change you make will result in a database change in Kentico, I find it much easier to be working on 1 database for development with distributed codebases. Otherwise you will probably need to overwrite the other database with your changes constantly and this can be annoying. If you leave the database on the server and just connect remotely, you can just ftp (or use git) to push files to the server that you have edited locally.
I have an application written in ASP.NET and using EF. I want to make a copy of the live database, have my application point to the copy, and be able to run the application against it as if it is live...but making updates to the copy.
I know I can manually copy the database and manually update the web.config files...but I'm wondering if there is a better, more automated method for achieving this with VS 2010?
Also, if there is anything I need to know about setting up a live/dev version of a database while using EF4.
You can switch the ConnectionString to point to the live or development database.
One way is to have different web.config files for debug and release builds.
Check out Web.config Transformation Syntax for Web Application Project Deployment
From my experience,
Setup 2 database connection entries in your config file, name one backup and leave the other ones name alone. Point your backup one to the backup db and when you want to run the backup, just change the names of the entries so the backup one is the actual name and the live one is named anything else.
Also, as for setting up different db versions - I'd just be careful that you don't update live by mistake!! and I've found it best to track changes to the db structure in a sql file so the live can be updated if needed or the backup can be rolled back if changes are made
I'm trying to compute statistics for data held in an Access .mdb database. In order to avoid interfering with the live database, I'm working from a copy which I made by simply using copy-paste in Windows Explorer. The copy resides in the same directory, but with a different name.
I'm using R and RODBC to connect to the copy of the file. The strange thing is that new data that is being updated on the original live database is appearing in my queries. This is despite the file timestamps of the copy not changing at all. It is also causing some slowdown in the live database.
My understanding is that the .mdb files are standalone, or is this not the case? Should I have copied the database in a different way?
It seems that you may have copied the front-end of a front-end / back-end set up. The back-end is where data is held and tables are linked to a front-end to hold forms etc. Copying a front-end copies the back-end links, so the data is live.
I'm trying desperately to move from VSS to a real source control system. Options include TFS and SVN.
My designers need to keep their ability to modify source files and instantly preview their changes in a browser without having to commit their changes. Using FPSE with VSS, this works flawlessly, since saving a file causes the copy in the working folder on the dev server to be updated, so they can just save and refresh their browser which is pointed at the dev server.
The site in question consists of 350k+ lines of classic ASP code and some new ASP.NET MVC. They only need to be able to modify views within the MVC code, not C#.
Though Expression includes a version of Cassini for local debugging, Cassini does not support classic ASP.
Surely someone has solved this problem before. It can't be necessary to install IIS on each designer's machine (this is absolutely untenable). I need a way to have a common working folder on a dev webserver updated whenever someone saves a file locally, just like using FPSE.
I'd rather not write an FPSE proxy that knows how to talk to TFS/SVN. Any suggestions?
(I know I've asked this question in the past, but I haven't yet found a solution.)
Why the need to copy the source files when they are saved, why not simply save the files to a network share and work on them directly? If the dev server is constantly being overwritten after every save anyway surely the effect is the same?
This probably won't be as instantaneous as you like, but with TFS you could set up a Continuous Integration (CI) build that builds and deploys the project to a test server on check-in. If you do this, you'll want them checking in to a QA type branch, then, once they are happy with how they look, they can then merge to the mainline branch for the real build and integration.