I'm in the process of evaluating db4o and I have a pretty simple question. Does the db4o configuration settings (e.g. Transparent Activation) and indexes need to be setup each time the application runs and/or the database is loaded, or can all this be setup at the time the database is created?
For reference - I'm building an Android application and the database is going to be prebuilt on the desktop and shipped with the app.
just as an FYI, there is an exception .. indexes once created are saved and will be used regardless of their specification at OpenFile/Connection time.
Best,
Robert
After more digging in the documentation for db4o I found my answer :)
"Configuration settings are not stored in db4o database files. Accordingly the same configuration has to be submitted every time an ObjectContainer/ObjectServer is opened. For using db4o in client/server mode it is recommended to use the same configuration on the server and on the client. To set this up nicely it makes sense to create one application class with one method that creates an appropriate configuration and to deploy this class both to the server and to all clients."
Related
I have been developing an application in Visual Studio Lightswitch (Silverlight client in VS2010 SP1 if it makes any difference), and so far have done all the database development in the Lightswitch designer.
I now want to use an external database, but don't want to recreate the whole app, or even just the screens. I have scripted the database, and have created a copy in SQL Server, but can't find out how to get Lightswitch to use this external database without starting the whole thing again.
Is there a simple way to change the connection string so that I can carry on from where I am, but have Lightswitch point at the external database instead of the internal one?
Turns out this is a very difficult thing to do. Super Lightswitch-hacker David Baker saw a post I'd made on the subject in the MSDN Lightswitch forum, and kindly offered to have a go at it for me. It took him several goes, but we got there in the end.
I wouldn't recommend this to anyone. I would strongly recommend using an external database right from the start. I can't see much benefit from using the internal one, and if you ever need more control over it, or want to switch to an external one, you've got major problems.
Hope this helps someone.
You must publish your project in order to create a new SQL database , publishing your project will create DB scripts for your new DB , don't use the internal LS DB to create script for your new DB.
I'm creating a simple MVC CMS for which I need a first time run configuration (to set up the database and admin user account, etc.).
The setup screen will ask them for the database connection string, so at first run, there is no knowledge of a database store.
How would I detect that this is the first time the application is being run, and take them to that setup screen?
Should I put a setting in the web.config with an initial value of false:
<add key="SetupComplete" value="false" />
And once the setup is complete, I can change it via:
ConfigurationManager.AppSettings.Set("SetupComplete", "True");
The downfall of this method is that, if the application is restarted, the config value will default to "false". What is a good solution to this problem?
Many PHP CMS doing the same thing you want to do, as it is the initial setup it would be OK that the admin change this value manually or you simply check the existence of a file which must be deleted manually.
As it is IIS app I would build a deployment package, so you can setup the the initial settings during the installation process, which is the common way for IIS apps I think.
In the past, I implemented a custom SettingsProvider (an example is here and here). Special care was taken regarding security, ensuring keys are encrypted. The samples isn't perfect. You can use the Application Settings provided by Visual Studio and .NET 2.0 to store settings in the format (e.g. xml) and location of your choosing (e.g. AppData).
It is a tad more secure than allowing your application to modify your web.config, since doing the latter means you have to elevate the privileges of your process which may be rather dangerous when your application is exposed on the internet.
It also simplify backups and upgrades.
As sf_sandbox has set up the symfony environment, why not develop in the sandbox directly and then upload on to server? What are the disadvantages of sandbox compared with configuring manually?
I think there is no drawback in following this approach. sf_sandbox is a pre-configured symfony project. One of the pluses is that is saves you time in creating your project and initializing an empty application (by default this is called frontend).
It's more a matter of taste rather than a matter of right or wrong. It's up to you!
Note: If you follow this approach you have to make some initial configuration (steps 1,2,3 would be done anyway if you started your project from scratch):
Rename the project
Change the config/properties.ini file
Change the config/databases.yml file (by default sf_sandbox uses sqlite database)
Remove the data/sandbox.db database file
I'm trying to upload an ASP.NET MVC 3.0 application to Windows Azure. The upload ok but the configuration (automatic operation just after upload) failed.
Any idea ? (I'm new in Windows Azure)
In the new portal you have to explicitly check a check box to allow deployment with less that two instances:
There is absolutely no obligation to use 2 instances. There is only SLA that comes into place only if you have 2 or more instances. I have production roles with 1 instance and I am very happy to use the Windows Azure services.
UPDATE
Just ntoed the "Linked Resources" comment on the first answer. So here are my 2 cents on it too: Linked resources feature is just a way for us developers to have a quick overview of our application and to quickly navigate between the components. There is nothing to do with our application's configuration files. You can set your Windows Azure SQL Database connection string as you normaly do with regular apps - in web.config (web.release.config)
The answer is right there in the second screen shot.
When you upload your package from the portal the dialog has a checkbox at the bottom that says "Deploy even if one or more roles contain a single instance" That needs to be checked if you are choosing to deploy to a single instance.
This is required since the SLA cannot be maintained with a single instance. There are times when the single instance needs to have OS updates applied or sometimes there are hardware failures. Having more than one instance is the only way to continue serving requests when one of these events occur.
You probably will not want to deploy a production solution with a single instance. But, for the dev cycle you can certainly get by with 1.
Does anyone have any good techniques for easily switching between development and live builds for asp.net mvc websites? Every time I make some changes I need to change to go through my web.config and comment out all my local stuff and uncomment all my remote settings. I also need to update the linq-to-sql dbml file to point to the right connection string.
This happens every time I make a change in a controller. After I upload the changes I then have to do the same process and get it back to development (local) mode.
Is there an automatic way to handle this, or at least one setting that can flag between the two?
Thanks
a way I've done is to make two groups of configuration settings
<LiveSomeSetting>something</LiveSomeSetting>
<TestSomeSetting>anotherthing</TestSomeSetting>
Then in my class that reads configuration info, I'd check on something like the system environment / computer name and if applicable to the name of your LIVE machine look at the settings... otherwise the development.
if (System.Environment.MachineName.ToLower().StartsWith("devMachineName"))
IsLive = "Test";
else
IsLive = "Live";
Application["IsLive"] = IsLive;
SomeSetting = ConfigurationManager.AppSettings[IsLive + "SomeSetting"];
I use a simple technique that Scott Hanselman blogged in '97. It basically involves maintaining separate web.config files for each of you build types. Then there is a pre-build event which copies the correct web.config into place.
It does have the down side of having to maintain 2+ web.config files but once you're up and running it isn't really that big an issue.
Have a look here at the article:
Managing Multiple Configuration File Environments with Pre-Build Events
HTHs,
Charles