After doing a test install of Orchard 1.0, I've decided I want to use regular SQL Server instead of SQLCE. How do I change the provider? And, how do I re-run the database setup?
Best thing to do is to delete all files from under your App_Data folder in Orchard.Web, this way you can start fresh :)
Edit app_data\default\settings.txt.
You should change the settings.txt, located in App_Data\Sites\Default.
In this file, the connectionstring and provider is stored as plain text, like so:
Name: Default
DataProvider: SqlServer
DataConnectionString: Data Source=server;Initial Catalog=dbname;User Id=username;Password=password;
If you are using the SqlCe DataProvider, the connectionstring will be null.
Change it to the appropriate connectionstring and change the DataProvider to SqlServer. Once this is changed correctly, you'll be able to use the supplied SQL Server.
To migrate the data from SQL CE, I've used this VS2010 plugin as you can't connect to those DB's yet out of the box: http://visualstudiogallery.msdn.microsoft.com/0e313dfd-be80-4afb-b5e9-6e74d369f7a1/
Hope it'll be of any use to you as deleting the App_Data folder will give you a lot more work.
Related
Attempting to view the a view or procedure:
from SQL Server Management Studio 17.4 in Azure SQL Datawarehouse notes the error:
I can however, delete and create any object that I want.
How can I work to ensure I can view the objects definition?
UPDATED
Concerning setting the options in SSMS to SQL Datawarehouse, there is not that option:
Please change this setting under Tools... Options. That should resolve the error. I wish we didn't have to change this but at lease we have a workaround.
In SSMS 17.5 there are a few more options. You can have it automatically detect what type of database you're connected to and script accordingly. Or you can force it to script for a particular database type like the following screenshot.
It appears there is a bug in certain versions of SSMS (such as 17.5) where if the DW user isn't also a user in the master database then scripting fails. The easy fix for this is having the server admin connect to the master database and run:
CREATE USER MyUserNameHere FROM LOGIN MyUserNameHere;
Sorry you're seeing this. I've been able to repro this on SSMS 17.4 and 17.5. We are looking at this now.
This seems to be a defect in the upgrade path for 17.5 as this should be supported without having to change the script settings. We are investigating this and will try to get an update out as soon as possible.
I currently have an ASP.NET Core 2.0 project and I've just implemented code first migrations to the localdb and have around 3 migrations including the initial create. I'm wondering what the correct process is to change to a new database? Is it simply a case of updating the connection string and running the below in the project directory?
dotnet ef database update
My current knowledge is based on the below Microsoft tutorial and I've been using the CLI commands.
https://learn.microsoft.com/en-us/aspnet/core/data/ef-mvc/migrations
In answer to my own question, it does appear that running the following command in the existing project directory will build a new database from scratch including all the existing migrations. As long as you update the connection string to the new database and have already implemented migrations on the existing database.
dotnet ef database update
correct process is to change to a new database
Everything depends what you mean by writing this sentence ( I am not sure what "new database" means in it) altough flow looks like this:
1. First you make initial create
2. Then you change something in your code (create some additional fields etc)
3. Then you write "dotnet ef database update" command in CLI to update your current database.
I'm using Entity Framework with a code first model; I've got my InitialCreate migration setup and working locally, I can run code against my database context, and everything works.
But when I deploy my project to Azure, I just get a connection string error ("Format of the initialization string does not conform to specification starting at index 0.").
I can't seem to find where in the Publish dialog are the options to create the Azure database. -- Do I have to create the database separately and hook them up manually? -- If so, what exact process should I follow. Does the database need to have contents?
I thought Microsoft was making a big deal that this could all be done in a single deploy step, but that doesn't seem to be the case from my current experience.
When you publish your project in the publish dialog, there is an option for the code first migration in the Settings tab, it will automatically show your data context and it will give you the option to set the remote connection string, and this will add a section in web.config to specify the data context and the Migration class to run during the migration process.
It will also allow you to set if you want to run the code first Migration or not.
You can also take a backup from the dev and clear the data then upload it to Azure SQL DB, this way the code first data context will check at first connection and it will find the code an database the same
I have added a new default ASP.NET 5 web app, and chosen to deploy to AZURE. This works fine, but if I retry and add a azure sql db, then I get the error below as it tries to create the new resource group.
Microsoft Visual Studio
Template deployment failed. Deployment operation statuses:
Failed: /subscriptions/81368473107b/resourceGroups/DJWTestDb/providers/Microsoft.Sql/servers/djwtestdbdbserver ()
error (InvalidApiVersionParameter): The api-version '2.0' is invalid. The api version must be of the following format: yyyy-MM-dd. This format supports the following suffixes: '-preview,-alpha,-beta,-rc,-privatepreview'.
Succeeded: /subscriptions/81368473107b/resourceGroups/DJWTestDb/providers/Microsoft.Web/serverfarms/DJWTestDbPlan ()
I've been running into the same problem, just registered to let you know. It seems that it isn't possible right now (who knows why, but I'm looking at you, ASP.NET RC1) to publish while deploying an SQL server. However, it DOES work to publish without one and make one in the portal, and then connect them through your Web.config.
At first I thought it was all of the new updates to Visual Studio (as of 5/12/15), but I was still getting the same problems after updating. I'm not sure if the new updates are required for this workaround, but that's what I was working with for this.
Steps:
1. Publish your API app as normal, without including an SQL server.
2. Go to your Azure portal and navigate to the "SQL Databases" tab.
3. Create a new database using your existing server, or just make a new database server if you don't have one yet.
4. When it's done (it may take a second for it to show up in the list), click on the new database and it's settings will appear. You want to go to the "Show Database Connection Strings" option.
5. Save the ADO.NET connection string!
6. Go back to your project in Visual Studio and navigate to the Web.config file.
7. In the "connectionStrings" header, find your database context. It should have a name formatted like YOURDATABASENAMEContext, or something similar. It'll probably be the second entry there. Replace (save a copy first, see note below for why) the inside of the "connectionString" with the ADO.NET connection string of the database you just created.
8. Publish and it should work!
NOTE: This workaround, if followed literally, means the program won't function locally anymore (e.g. starting the app rather than publishing it) since it will be looking for that database in the connection strings. You could return it to it's original state for testing, and then use the azure connection string when publishing, although I'm sure there's a more elegant way to do it.
I've created a portal-ext.properties and added:
jdbc.default.driverClassName=oracle.jdbc.driver.OracleDriver
jdbc.default.url=x
jdbc.default.username=y
jdbc.default.password=z
schema.run.enabled=true
schema.run.minimal=true
And I've added my ojdbc5.jar to lib/ext.
However when I run my startup.bat the database isn't being generated?
Does anyone know why this is occuring?
Check to make sure that the database is up and running. Can you log into Oracle using SQL*Plus or some other client using the credentials you've provided? If you can't, Liferay won't be able to either.
Can you try using lifery's Data Migration feature? You can start your server with default HSQL script and then try to migrate (which can automatically create tables as well).
Go to Control Panel->Server Administration.
- Enter the values in section Migrate from One DB to another and click execute.