I'm still rather new to java and I think I've started a project with a problem.
I created a job for a friend in which there are employees, shifts, sites and these needed to be loaded at the beginning.
I went looking for solutions and decided to use a Derby database. I've now programmed the Application and it works fine with the database. It loads all parameters and creates objects for handling,
Now I need to deploy my project to my friends computer so he can use it and I think I have the database set up wrong. I think I needed it to be embedded? so it goes with the application.
So my questions are what are my choices,
I read I can change the database to an 'embedded' one by making the database a class? I have no idea how to do this and maybe because I'm new to java, I'm finding all the write ups on this subject difficult to understand.
Alternatively I thought maybe I can install Derby separately and connect to that?
Or maybe I can drop the Derby idea and switch entirely to another database entirely,
I'm a bit confused over my choices here, basically I've built an application around an installation of Derby DB using this line to connect to it.
jdbc:derby://localhost:1527/SG_database
If someone can give me some 'Plain English' options here I would very much appreciate it.
To reconfigure your application to use Derby as an embedded database, all you have to do is change that JDBC Connection URL to jdbc:derby:SG_database, and change your CLASSPATH so that your program references derby.jar rather than derbyclient.jar. You should possibly add ;create=true to the end of that URL so that, the first time your friend runs your application, the database is created on their machine.
But yes, you have other choices, and without knowing a fair amount about your application it's hard to give you very detailed guidance.
When your friend is using the application, do you want you and your friend to be sharing the same set of data? Or is your application designed so that your data and your friend's data have nothing in common?
If you want to be sharing the data, then yes it will be important to have a single instance of the database, and both of you have to share it, in which case a client-server configuration can work quite well.
If you want to be two completely separate applications, with nothing shared, and each of you has your own copy of the data, then an embedded configuration can work quite well.
Perhaps you could simply try the embedded configuration, see how it behaves with your application, and then return here if you have a more specific question to ask?
Related
I am brand new to the concept of embedded databases and have chosen HSQLDB to be the embedded DB for my Java app. I think I am fundamentally not understanding something: nowhere do I see how/where to:
Define username/password credentials that must be used for connecting to a database
Creating a new database (e..g, db_myapp)
Creating tables for that new database
With a non-embedded ("normal") DB, I would first use a DB client to connect to the database, and CREATE the db_myapp DB as well as any tables it should have. My app would then expect those tables to exist at runtime.
But with HSQLDB, I have no such DB server to connect to, so I don't see how/where I can create these databases/tables/credentials ahead of time, before my app runs.
And maybe that's exactly what an "embedded" DB does; perhaps its an entire DB embedded inside a JDBC driver? In any event, I still need a way to accomplish the 3 things listed above.
The only thing I can think of is to run some initialization code every time that my app starts up. This code would check for the existence of these constructs, and if they don't exist, then it would create them.
There are several problems here:
This approach might work with databases and tables, but not the credentials I need on the JDBC Connection itself. How/where do I create those?
I'm not even sure if this is the right/normal approach to using an embedded HSQLDB; can someone confirm I'm on track (that is, the "check-to-see-if-it-exists-and-if-not-then-create" approach)?
What happens if I accidentally execute code that tries creating a new database/table eve when it already exists? Will HSQLDB just ignore it or will it blow out my existing DB/tables?
The short answer is that you're pretty much on the right track.
Connecting to the embedded database is really no different from connecting to a normal db server, except that the connection string is a bit different. This section has information on that. The thing is that you don't really have separate 'databases' to choose from, it's just specified in the connection string. For the connection:
Connection c = DriverManager.getConnection("jdbc:hsqldb:file:/opt/db/testdb", "SA", "");
This will give you a connection to an embedded database engine that persists the data in the file at /opt/db/testdb. The default username for an embedded database will always be 'SA' with no password. I honestly don't know if it'll work, but if you really need to set a different password, you can try executing ALTER USER SA SET PASSWORD <newPassword>. It'll probably work...
As far as creating tables and such, there's a couple of way of going about this, depending on whether the database will be persisted as a File or in memory. Often times, embedded dbs get used for pretty simple data, and so the tables get created by executing a statement right after initializing the connection. CREATE TABLE IF NOT EXISTS ... is the usual way of doing things. This allows you to create a table only if it doesn't already exist.
If you're working with a file-base database, then hsqldb gives you another option. Take a look at this documentation about accessing a database using their tools. This would allow you to create a file-base database ahead of time, and set things like username/password and setup all your tables. Then you can just copy over the resultant file to be used by your application. Then everything would be setup before your application connects to it.
So ultimately, you have the option to go either way. You can either have your application set everything up when the connection is initialized, or you can set it up manually ahead of time. My preference is to have the application set it up in code simply because then your table definitions are kept closer to the code that actually uses them. I haven't used an embedded database like that for really complex data, though, so I can't honestly say how well that scales.
I read a lot of posts like:
querying embedded database in netbeans using derby
But still I'm having trouble to understand embedded databases.
1) I create a Derby database on Netbeans and I can create tables, link the database to a form and submit the data and update the records with no problem.
2) The problem arises when I want to make the program portable. I apply Clean and Build, then copy the dist folder and also copy the libraries, database, etc ... but when running the program does not recognize the database
3) I read in several places that it is appropriate that the database is created by code using something like
String host = "jdbc: derby: // localhost: 1527 / EmployeesCreateTrue; create = true"
and not creating the database on Netbeans Service...
If I do this procedure with code the database is created but it does not appear or does not allow me to connect from NetBeans and I wish I could fix it to create tables from NetBeans and not from code.
4) I read manuals "how to import a database from Derby to NetBeans" and it doesn't work...
Question: What is the best way to create a database, tables and connect to NetBeans for the final application to be easily portable?
1) Create the database on Netbeans with the wizzard?
or
2) Just plain code on the application?
I don't understand precisely what you mean by "the database is created but it does not appear."
I think if you were to explain that precisely, the community could probably help you.
There are three common reasons for "table does not exist" when you think you've created the tables; I've explained those cases in this answer: Is it necessary to create tables each time you connect the derby database?
Please let us know more information about your situation so that we can help you better understand the behavior of your application.
I'm not 100% sure if this is your problem, but a lot of problems people seem to have with Netbeans and Derby seems to come from the fact that they don't set derby.system.home explicitly. When you don't, Derby stores databases in the current directory, and that is likely different when working in the IDE, either in the Services tab, or your own code, than when you execute your app's jar as a standalone program. So the advice (which you will also find in the manual) is: always set derby.system.home. An alternative would be to use full paths to the databases, but that rarely works well for a real application that is deployed on different machines.
I had the same problem --had the derby db in the services but the netbeans coded programs didn't access it. I solved it by adding the derby database (copy paste) to the package in the Files section. I use Windows 7. Once I did that, I was able use multiple tables (before netbeans just ignored secondary tables and only allowed me to use the primary table).
Up until this point, I've been using Spring in a development mode of sorts with hbmddl2 properties which drop all the tables and start again when I deploy the application to glassfish. It works well as a development config, since I know exactly what my database is going to contain when I run my app.
However, this isn't appropriate for an application with a rolling release cycle and I'm not exactly sure how to proceed in changing it so it would be suitable in a production environment. Googling it just gives me resources on how to update Spring or Hibernate itself, but nothing on maintaining a server. I'm getting the feeling I'm going to have to start creating XML object property mappings for Hibernate, but I think that's a little over the top when all I want to do is update a schema with new tables and new columns with default values.
Thanks in advance for any answers, I'm completely stuck on this.
This question is a matter of opinion so is is very broad.
There is no best way or right way of doing it.
Updating/upgrading/versioning etc. a production database is always a risk based activity where the key is to mitigate the risk as much as possible.
Here is a example answer to your question Best Practice for Updating a Production Database manually.
This is one of those areas where you gotta do your research and find the best deployment/upgrade method for you. At the end of the day you are going to be accountable for any user/customer data in your database so you have to be comfortable with the approach.
My aim is to create a local database that can be read and written to with Java. I have some experience with manipulating a local sqlite database with Python, and with interacting with existing networked databases on Microsoft Azure via VB.Net, but the Java formulation for creating a database is escaping me.
Most sources (like the JDBC Docs) seem to assume that you are accessing a database through a network protocol, or a database hosted on localhost. My desired implementation is to create and store the database in a file (or collection of files), so that it can be stored and accessed locally, without network connectivity (presumable through the "file:" protocol).
The JDBC Tutorial looks like it will be very useful once I am up and running, but is currently beyond my scope, since I don't even have an existing database yet.
Many sources have suggested solutions like H2, MySQL, Derby, or Hypersonic DB. However, I'm loath to install extensions (if that's the right term) for a number of reasons:
This project is initially intended to help me learn my way around Java - widening the scope of the project will dilute my experience with the "base" language and, probably, increase the temptation to engage in "cargo cult programming"
If this project does ever get distributed to other users (admittedly unlikely, but still!), I don't want to force them into installing more than the core of Java.
I simply don't know how to install extensions (add-ons? modules?) in Java - one baby-step at a time!
For similar reasons, installing Microsoft SQL Server would not be productive.
This answer looks close to what I'm aiming for; however, it gives the error:
java.sql.SQLException: No suitable driver found for jdbc:mysql://localhost/?user=root&password=rootpassword
and trying "jdbc:file://targetFile.sql" gives a similar error.
I've seen the term "embedded" database, which I think is a subset of "local database" (i.e. a local database is stored on the same system - an embedded database is a local database that is only used by a single application) - if I've got those definitions wrong, please feel free to correct me!
Most likely, the reason for which you are getting the error, is due to the fact that you are not registering the driver (using reflection...) before actually using it for establishing a connection and so on.
Presumably you will want to do something along the lines of Class.forName("driver")
and then cast that if necessary and then registering it in the DriverManager before calling the getConnection() method.
Here is a very useful link that might help you out in solving the issue:
http://www.kfu.com/~nsayer/Java/dyn-jdbc.html
However, if you really want to use a local database/file you might want to have a look at SQLite, that might be one way to go about it, although I recommend going for the MySQL approach, as it is a lot easier to configure and learn how stuff works with JDBC.
If you are still considering SQLite check this out:
Java and SQLite
I see you need some guidance in importing external .jar files into your code (i.e. 3rd party libraries like the ones you will be using for a JDBC driver). Are you using an IDE (e.g. Eclipse, Netbeans, etc.) or are you writing in a text editor and compiling manually?
A number of embedded pure Java databases appeared recently, which have a really simple interface, usually just java.util.Map, don't involve using JDBC or other SQL artifacts, and store their data in a single file or directory:
Chronicle Map
JetBrains Xodus
MapDB
The main downside is that most of such databases provide only the simples key-value model.
DBC can be used with any database that has a JDBC driver, which isn't necessarily a database in "network mode", it can be used with embedded databases as well.
Here are some Java and embeddable databases:
http://www.h2database.com/html/main.html
http://db.apache.org/derby/
http://hsqldb.org/
Java's JDK does not include any implementation of a database nor drivers to access it. It only provides JDBC as an abstraction to connect to a "database". Is up to you to include all the needed libraries in your code.
If you want to have a self contained code you can simply include the .jar file of a embeddable database in you classpath. That way you can create the instance of the database in your code and minimize the external dependencies.
You can find here a list of java embeddable databases
You can find here an example of how to embed HSQLDB in your code.
I am working a project that will require a custom "wizard" to help a non-technical user to install a custom database driven application. The main concern is to not set up a new database for the custom application if there is a suitable database engine already in place. So the question comes: how to programmatically detect the type and location of existing database engines?
The trick here is that the requirements for the installer are that the wizard assists a non technical user decide if a database engine exists on the local private network that is on the compatibility list. If so, assist the non technical user with forming a connection to the selected database engine. Otherwise the wizard is to install a database etc.
Would it be better to just install the preferred DBMS regardless of the existing database scene? The platform is a windows box, but platform independence is a goal of the project.
I don't know if I am just using the wrong search terms or if there is little to no real information to this effect, but finding out if this is even possible has been frustrating.
Any help, advice, links, code resources, etc. will be greatly appreciated.
EDIT The goal of detecting the location and type of existing databases is to provide a simple list that a user can select from, for the case of adding an additional instance of the application on a private network for the current version or as an upgrade of the version (to effect a "clean" install). The application is a bit distributed in that there are typically going to be many instances of the application (3 - 10) working as terminals to interact with the database, manipulating the information in different ways for different uses on different terminals. The I think the preferred DBMS has settled on PostgreSQL.
Steve
If you know what type of database you're trying to connect to, you should be able to ping the default port for that type of database to see whether it returns a response. Or alternatively, try to open an actual connection to the database and see whether you get a response.
Getting more complicated, if you can access the PC on the network, browse to the default installation directories for the database type to see if anything exists.
These 2 so far would require the database to be installed using default locations and ports.
Getting more complicated, if you can connect to the registry on the remove PC then you can probably locate the database in the registry tree - this is going to be fixed no matter where the user installs the database
My suggestion would probably be to completely avoid this though, as it adds a lot of complexity without much payback. If your application is for a non-technical end user, it'd probably be better to just assume that there isn't any databases available to them, and just install a new one as part of the installer. Non-technical users are only going to be confused if you present them with a whole list of database options that really don't mean anything to them.
It could also potentially take a long time to query your local network, depending on how many network shares exist, and how quick they are to respond. All this would take away from the responsiveness of the installer, so the end user might not know why the installer isn't doing anything.
If you really want to give the option of choosing an existing database, I'd make it a separate optional button which would take them to another screen where they can choose a network host to investigate - the only people who would get to this screen would be more technical people who would probably know where a database exists anyway.
The main concern is to not set up a new database for the custom application if there is a suitable database engine already in place.
I don't quite understand how a wizard can determine whether an existing database is suitable. Suppose it finds 3 Oracle and 4 MySQL instances on the network – how will it choose? Moreover, such an approach creates a dependency between the user's application and another machine on the network, without the user's even being aware of it. What will the user do when the database's unavailable tomorrow?
It seems to me that if the data needs to be shared among several users or several systems, then selection of the DB must be an explicit, conscious operation by the user. If, on the other hand, the database is just a place where the application stores some stuff, then it should install one – preferably a lightweight one like HSQLDB or SQLite.