Screwturn wiki to point to existing database will not work - installation

I recently moved my screwturn installation to a completely new environment (site on new IIS/server and database moved to new SQL Server).
I can succesfully open the Screwturn wiki but instead of using the existing database (that I configured in the web.config), Screwturn wants to create the DB from scratch and hence states the error that certain tables already exist in the DB.
If I create a blank DB and use this in the web.config, Screwturn will happily create its tables and use that DB. Of course, that's not what I want, I want it to use the existing, moved DB on the server.
Is there a way to tell Screwturn not to create the DB and simply "use" the existing one?
If this is not possible, are there scripts available to copy the content from the old DB to the new one (simply copying it with SQL Servers Import/Export feature gives errors (logical) that certain fields cannot be created as that will cause PK violations.

Did you use your old web.config or just update the SQL connection info in the web.config from the new version? I think you should use your old web.config (maybe compare to the new one to see if anything was added). I have done this several times with several installations and haven't had a problem.
The only other thing I can think of off-hand is if your old version is v2, then you should review the instructions here as a few things changed from v2 to v3.
Old Screwturn Wiki Site - Upgrade from v2 to v3

Related

Is Oracle Database Supported in Joomla?

I would like to use Oracle database instead of MySQL in Joomla. Is this possible with Joomla, is there a workaround or a solution on how to implement Oracle database with Joomla? Any information will be greatly appreciated.
It is said that it can be done, but it is not a job for beginners and took those guys 3 working days to do it.
Here's why that combination doesn't work by default:
The database and table creation script does not work without modification.
The connection and the database class are written to connect to MySQL and not to Oracle (so they all use MySQL functions).
Some of the extensions use native MySQL functions directly, instead of connecting using the Joomla Database interface (class).
This is what they did to make it work:
We fix the SQL installation script to accommodate the Oracle database in case of a new installation. In case of an existing installation, we export all the database, as well as its data to a SQL file, and then we modify the SQL file (using find and replace) to make it work with an Oracle database.
We load the modified installation file or the modified exported SQL file into the Oracle database.
We then create a copy of the Joomla database class, and then we modify all the functions to work with Oracle instead of MySQL.
We ensure that the Oracle drivers are properly installed and loaded by the php.ini file.
We rename the original MySQL database (you will know in the next step why) to something like database_name_old.
We switch to the new database class and fully test the website to see if some extensions are not working. If an extension ceases to work then it is a sign that this extensions is calling the original MySQL database (which no longer exists because it was renamed) directly.
Hopefully, you aren't a beginner and those guidelines will help you do it. Otherwise, check how much it might cost by visiting the page.

Production Database Creation / Migration dilemma for ASP.NET Core MVC

I have been building my ASP.NET Core MVC web application since last year and there are currently 100 migration files in my project, as the database has evolved along with features and capabilities. My development / test database is obviously in sync with this migration.
Now, the time has come to create a Production environment, and I want to have an empty database with only the table schema. So, I just can't copy my test database to create a production database.
So, the question / dilemma I have regarding creating this Production database is as follows;
1. I can either create my Production database by running Add-Migration command (for which I need to delete existing migration files from the project), or
2. Create table schema in SQL Management Server, and keeping the __EFMigrationsHistory from test database
With [1], I am not sure how I will be able to manage my test database with this same project, going forward.
With [2], I am not sure if there is any drawback.
So, what is the standard or best practice for Production deployment?
You can certainly use Visual Studio to create or update database tables, but this would normally just be in your development environment.
If you are worried about the number of migrations you have, you still have the option of starting over by deleting them, and deleting your migration history (and manually deleting your tables and data) and creating a fresh 'Initial create' migration. If you do this you will probably want to export any test or config data first, or make sure you have a way to recreate it.
For the staging and production deployments, best to use SQL Server Management Studio to generate a script to build your tables. The database administrator - or you if it's just you - can create the database and run the script to generate the tables.
This is because staging and production environments tend to be more tightly controlled than development, so best to understand the processes that are most appropriate for the environment.
You need to check that your dev and staging/production SQL databases are set at a matching 'compatibility level', and also need to decide whether you need to add any seed or configuration data on create.
In SQL Server Management Studio, select the appropriate option to generate a script for the required tables.
https://learn.microsoft.com/en-us/sql/ssms/scripting/generate-scripts-sql-server-management-studio?view=sql-server-ver15
You can also use this process to export, and import data - this is ideal for config or test data.
https://dzone.com/articles/generate-database-scripts-with-data-in-sql-server

What is incremental database publishing?

When I am publishing my site using Web Deploy in Visual Studio I see something like:
MySql.Data.MySqlClient is not supported for incremental database publishing.
I want to know what exactly would this technology do if it is supported?
Incremental database publishing is a deployment feature where the source code for the schema (new version) is compared with the live database schema (current version) to create a change script to upgrade the current version to the new version.
For example, if your schema has a table with a few columns and in the source code you add a new column definition, when publishing it would create a script to add the new column to the table.
It's not surprising that a database engine besides SQL Server isn't supported, since supporting other database engines would be a significant amount of work. All it really means is that you'll have to synchronize database changes yourself. MySQL may provide tools to help with this, but Visual Studio doesn't.
Incremental database publishing is used for versioning purposes. SVN can't really handle versioning for database schema like tfs can support.
If you're using incremental database publishing you can set up to keep the current database and just do the update, or to always recreate database.
Let's assume you want to declare sql variables like InitData, SeedData.
You can do this and you have access at some before and post publishing script. If your variable SeedData is true, you can seed some data in the post publishing script.
More info here: http://www.asp.net/web-forms/tutorials/deployment/web-deployment-in-the-enterprise/deploying-database-projects
EDIT: it's just the schema that's updated if you choose not to recreate your database when you publish

Deploy Entity Framework Code First Database

I have an ASP.NET MVC 3 application using an Entity Framework (4.3.1) Code First database. Now I would like to create a comprehensive zip file containing the database, the application package generated by Visual Studio 2010 and a script to deploy everything to a Windows 2008 server with IIS7 and SQL Server 2008 with a prepared (but empty) database.
I don't foresee any problems with the deployment of the application package, but I'm unsure of what approach to use in deploying the database. The target environment already has an empty database that's been assigned to me, but I've been told that dropping and creating the database is fine.
From what I've read, I can do a straightforward copy of the .mdf and .ldf files to the server and then setup my connection string to point to that specific file but this approach sort of ignores the database that has already been created (or at least named) for me. The other approach would be to use the the existing .mdf to create the database on the server with a script. My only issue here is that I would like to keep the database name assigned to me.
I usually connect to my development database locally using SQL Management Studio and right-click the database, choose Tasks -> Generate Scripts. Then I select the entire database or just the tables I'd like to keep, click next, then click the Advanced button and make sure that I am scripting out "Schema and Data", and then generate a sql script that I can run on the production database, therefore keeping the table structure and the data that was in the dev database. Obviously, if you don't want to keep the data then just script out the Schema only. Then, point your application's connection string to the new production environment database and you're good to go.

Using a VS2010 Database Project for only specific schemas in another database

thanks for reading...
Here's my problem:
The Background: I have been tasked with being a Build Manager (first time doing so). Among other things, this includes creating scripts to update the staging DB. I would like to utilize a Database Project for this so I may keep it in source control and also have it apart of TFS Labels to create a snapshot of the DB at the time of the build. This seems pretty straight forward to me.
The Setup: In our dev environment, we have a copy of our production DB. This DB is the one where our new data base objects will be deployed when we go live. We also have a copy of it in staging for testing.
The Goal: The only schemas (and related objects) I need in the Database Projects are limited only to the ones that aren't in production.
The Problem: When I create a new Database Project, I have no option to select only certain schemas to import (that I am aware of). Is there a way to only import Schemas A, B, and D and leave out dbo and C? Along with this, is it possible when using the 'Schema Comparison' to compare only selected schemas within the database?
Please let me know if my question and information are incomplete.
Thanks.
-Justin

Resources