I'm developing a grails app that uses reentrant locking and database locking. I just noticed some additional files that were autogenerated. I am wondering what they are. They are called:
devDb.h2.db
devDb.lock.db
devDb.trace.db
There is also a set for test configuration:
testDb.h2.db
testDb.trace.db
I am assumming that *Db.h2.db is just my database (set to be a file rather than in memory in my DataSource.groovy). But what about the other ones?
devDb.h2.db is the database itself. ( devDb.mv.db for the newer version )
devDb.lock.db is a lock file. H2 allows multiple processes to share the database and this file is used to coordinate access. When the database shuts down cleanly, this file should be removed automatically.
devDb.trace.db is just a log for inspecting or debugging H2. Whether or not it's created and how much detail gets logged can be controlled by adding a TRACE_LEVEL_FILE parameter to the JDBC URL.
testDb.h2.db and testDb.trace.db are the same as the devDb counterparts that are used in the test environment (e.g. grails test-app).
Related
I have a Microsoft Access File that is a shared file. Advanced settings set it to shared by everyone, Default open mode is Shared, No record locks, Open databases by using record-level locking. Enable DDE Refresh and default encryption.
Multiple users can open it at the same time, however if I save I get this message: Microsoft Access can't save design changes because another user has the file open…(etc.)
Any advice on where to begin?
UPDATED INFORMATION:
Apparently the database is already split, so I'm going to do some research in this area. Let me know if you have seen this before and can help though!
By definition, you cannot make design changes when another user is using the file.
Multiple users can access and edit records at the same time. The settings you set, control how strict the locking process is in order to avoid conflicts.
Design changes, not possible, no way!
I have 2 branches in Git - staging and production. They are deployed to the same VPS where there is one production database and a separate staging database. This allows us to stage new features without affecting the production environment. Then, when we're ready, we replicate the database changes from staging to production.
What is the best way to set this up so that the staging branch has separate database credentials to production? At the moment, the database creds are stored in a single file. I've been thinking about using gitignore to ignore this file in both branches and edit it manually so that it remains different on each branch. Is this the best thing to do or is there a better way?
We use a cascading approach:
Default settings are in a common "config" file.
For each stage of development, it has its own configuration file, for example we have a config_prod and a config_dev.
Each stage runs as a different (system) user, and for that user we set an environment variable PROJ_SETTINGS and point it to the file that we need to load.
The code then read the defaults, and then overrides them with whatever is available from the resource pointed to by the environment variable (if it exists).
Setting of this variable is taken care of by our normal devops/automation scripts. We have a few advantages:
Keeps all configuration under version control.
Easy to switch settings without modifying the source.
Yes gitignoring the database.yml file is an approach I've used in a few organizations.
We usually keep a database.yml.sample in source control so make it easier. Users just copy that to database.yml and modify as appropriate.
question for you.
So I have this Access 2007 database that I'm trying to lock down so that it can be deployed. The intent is for multiple users to run the front-end application simultaneously, connecting to the back-end tables over the network. However, I obviously don't want to give them access to the forms, settings, tables, etc.
I already tried using the ChangeProperty function for
AllowFullMenus
AllowSpecialKeys
AllowBypassKey
AllowShortcutMenus
AllowBuiltInToolbars
AllowToolbarChanges
AllowBreakIntoCode
But whenever anyone without macro's explicitly enabled opens the database, everything opens as if none of these settings are set. How can I get around this? I only use like 3 macros in the program, and none of them are related to the opening of the database or locking down the database.
Suggestions?
Thanks.
You can try distributing your front-end as a locked ACCDE file, this is the equivalent of the old MDE files from Access 2000. Details are available here: http://www.databasedev.co.uk/convert_to_accde_format.html
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...
I am working on a new web application using Scala with Lift. I want to make it reusable so others might install it on their own servers for their own needs. I come out of a PHP background where it is common practice to create an install form asking for database connection details. This information is stored in a configuration file and used by the rest of the PHP application for connecting to the database. It is extremely convenient for the user because everything is contained within the directory storing the PHP files. They are free to define everything else. My Java/Scala background has all been enterprise work where an application was only intended to run on the database we setup for it. It was not meant to be installed on others' web servers or with different databases.
So my question is how is this typically done for the Java/Scala world? If there are open source applications implementing the mainstream solution, feel free to point me to those too.
I use this to set up the database:
val vendor =
new StandardDBVendor(
Props.get("db.driver") openOr "org.h2.Driver",
Props.get("db.url") openOr "jdbc:h2:mem:db;AUTO_SERVER=TRUE",
Props.get("db.user"),
Props.get("db.password"))
LiftRules.unloadHooks.append(vendor.closeAllConnections_! _)
DB.defineConnectionManager(DefaultConnectionIdentifier, vendor)
The 'Props' referred to will then be (by default) in the file default.props in the props directory in resources.
Updated: This is what I do on servers in production. With 'Props.whereToLook' you provide a function that retrieves an input stream of the configuration. This can be a file as in the example below or you could for example fetch it over network socket.
You will probably let the application to fail with an error dialog.
val localFile = () => {
val file = new File("/opt/jb/myapp/etc/myapp.props")
if (file.exists) Full(new FileInputStream(file)) else Empty
}
Props.whereToLook = () => (("local", localFile) :: Nil)
I am not sure if I am missing your points.
By default, Lift use Scala source file(Boot.scala) to configure all the settings, because Lift doesn't wanna introduce other language into the framework, however you can override some of the configurations using a .properties file.
In Java/Scala world, we use .properties file. It's just a plain text file used for configuration or localization etc,just like text configuration files in PHP.
Lift Framework has it's default support for the external database configuration files, you check out the code in Boot.scala, that's if a .properties file existed, the database will initialized using the connection configuration, if it doesn't, it will use the source file configuration.