Message-ID: <1650952307.1493.1429935888243.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_1492_1898424198.1429935888243" ------=_Part_1492_1898424198.1429935888243 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
ODBC can be used as a layer between app servers and databases. It is qui= te convienent to setup an ODBC connection at installation time when the ins= taller can actually retrieve all info needed for such setup. How can we ach= ieve that? And for which OS ?
After looking at many solutions, I found one that is very convenient in = the sense that it applies to both Windows and UNIX environment. In fact, th= e Windows ODBC Manager applet offers two type of setups:
The system source writes in the Windows registry and unfortunately does = something else that I couldn't figure out. However, the file source is very= similar to ODBC.ini under UNIX. In ODBC.ini, you can define all connection= s into this file. For Windows it's a bit different as you will have as many= files as connections. But even though, there's a trick!
A fileDSN (the name given to this type of connection) for a connection t= o an Oracle database will look like this :
Therefore by changing the UID and PWD, you can make your connection poin= t to any schema that you want.
In my company's software, we use ODBC to make the connection between the= application and the database. Therefore, we use a batch file to launch the= server with a bunch of parameters. One of them is the ODBC DSN. This one, = using fileDSN, should be defined as follows:
A very nice trick is to put the UID and the PWD in this batch file&= nbsp;so that it's not needed in the file directly and therefore you make th= e installer create different batch loaders for different schemas ! That's v= ery useful when you have many schemas in the same DB and you want the = same application server to access any of them without reinstalling the whol= e thing !
In the following discussion, I'll show you an example of how to prepare = the installer for creating a file at the root of the installation path whic= h will permit the application to connect to an Oracle DataBase.
<file src=3D"dsn.dsn" targetdir=3D"$INSTALL_PATH"= /> <parsable type=3D"shell" targetfile=3D"$INSTALL_PAT= H/whateveryoulike.dsn"/>
Now during the installation the user will be prompted for the parameters= (UID, PWD...) and the file will be parsed.
Pretty simple !
What about SQL Server or another db? Well, there are many ways to do it,= a simple one would be to have a skeleton for each kind of db and then duri= ng the userinput ask for the database type (DB2, SQLSERVER,ORACLE...) and s= witch to the corresponding file before parsing.
Let's imagine you choose SQL Server in the userinputpanel, then instead = of copying whateveryoulike.dsn, you can copy whateveryoulikeforMS.dsn which= looks like this:
In our installer, we create four packs, one for each DataBase. These pac= ks copy the corresponding file and parse them. Again, pretty simple !
Another remark, is that in this way, if you choose more than one pack, y= ou could setup more than one connection at once on different DBs as long as= UID and PWD are the same. If not you'll need a little trick...
I hope this helps and if anyone has a question, don't hesitate to contac= t me via `http://developer.berlios.de/= sendmessage.php?touser=3D12462` or post into the user/devel list.
Done by Fabrice Mirabile on 20th of april 2005
in many cases, there is a need to have a relation between job being= executed with the processpanel and a pack. Since IzPack doesn't yet provid= e such feature I worked out something that does the job.
I'll explain it using an example on how to execute a Java class that run= s SQL statements.
Here is what you will need:
Which are at the root of the installation folder.
Then you could have a folder with the SQL files, let's call it update. S= o in update you'll have:
In these folders you can have any number of SQL scripts. For examp= le, the scripts could include: delete from task_category; insert into task_cat= egory values('LoadSource','Data Source Loading','source_loader_task.= bat');
Once you have this tree of files prepared, you need to setup each file. = The idea is that the install should copy the SQL scripts depending on the p= ack(s) chosen, plus the class and the batch file and then run the batch usi= ng the processpanel job. Therefore only the scripts for a specific pack wou= ld be run and there is the dependence we're looking for!
JDBCGeneral.java: (of course you need the compiled .class !!! bu= t I'm showing the source code)
To sum up:
The install.xml copies the files, the userinput asks for the DB connecti= ons, the process.xml launchs the class which takes as arguments the followi= ng entries:
Once again, i hope you'll find this useful and if anyone has a question,= don't hesitate to contact me via `htt= p://developer.berlios.de/sendmessage.php?touser=3D12462` or post into t= he user/devel list.
Done by Fabrice Mirabile on 20th of april 2005