Application Writing to Incorrect Library
I'm trying to avoid posting code here at first, because I really dont know where to begin, so I've explained the situation as detailed as I can - if code is needed, I'll gladly post whatever is requested. I'vebolded the basic question...
Hi,
I've just started updating an application which connects to a DB2 database. The first task I was given was to have the application connect to a different library on the database. The program uses a .properties file to determine which library to connect to, so all I've done so far is:
1) Copy the program to a testing directory
2) Edited the properties file to the new library name
3) Edited the batch file that launches the program so that the paths refer to the testing directory rather than the "real" directory
This appears to have worked, as we've migrated files to the new library and the application seems to be reading them. The problem that has arisen occurred when I tried to use the "real" version of the application.
I tried to modify an entry in the database with the "real" application and the change would not appear after I applied it. This was confusing enough. Then I came into work this morning about opened the "test library" version of the application, and lo and behold the changes I'd tried to make to the "real" library had appeared in the test version.
I'm really at a loss as to why this might be happened, but one suspicion I have is that the connection isnt being closed. I can't find anywhere in the code where a .close is used. Is it possible that this is causing the problem? In other words, I opened a connection in the test version the day before, and then the next day when I try to use the real version the old connection to the test version is still open and the changes I try to make are written there?
I know that it is best practice to close these connections anyway, but where do the close commands go for a GUI-based application? I guess the behavior should be that when you click the x to close the GUI the database connection should be closed as well, but I dont know how to handle this (I'm pretty new to GUI-based programs).
I know this post couldn't be more vague, so I'm hoping someone will be able to kick me in the right direction. Thanks in advance for ideas and help.
EDIT: I decided I should at least post the connection code
session.startIBMAS400AccessSession("jdbc:as400://facts1.facts.uillinois.edu;libraries=" + db_lib);
where db_lib is determined by the .properties file
Here is startIBMAS400AccessSession:
publicvoid startIBMAS400AccessSession(String sourceURL){
try{
// Load the JDBC Driver
DriverManager.registerDriver(new com.ibm.as400.access.AS400JDBCDriver());
// Connect to the database with authentication
c = DriverManager.getConnection(sourceURL);
// Get the user's ID
DatabaseMetaData dbmeta = c.getMetaData();
user_id = dbmeta.getUserName();
if (user_id.length() < 10){
for (int i = user_id.length(); i < 11; i++)
user_id.concat(" ");
if (DEBUG)
System.out.println("user id: " + user_id +" length: " + user_id.length());
}
// Alert the user they're in!
System.out.println(getDateTime() +": Project Log session started.\n"
+"Celebrate, " + user_id +"! You're in!\n");
}catch(Exception e){
System.out.println("\nERROR: " + e.getMessage());
}finally{
}
// Get user session profile and preferences
if (c !=null){
setUserRole();
prSearchHM = selectDefaultSearch(Search.PROJECT_SEARCH);
trSearchHM = selectDefaultSearch(Search.TRAINING_SEARCH);
hdSearchHM = selectDefaultSearch(Search.HELP_DESK_SEARCH);
crSearchHM = selectDefaultSearch(Search.CODE_REQUEST_SEARCH);
tuSearchHM = selectDefaultSearch(Search.TABLE_UPDATE_SEARCH);
getUserPreferences();
}
}
Message was edited by:
VP.
[5102 byte] By [
VP.a] at [2007-11-26 17:31:49]
# 1
Wow,
This sounds like a combination of a poorly constructed development environment with few safe guards in place and badly written or simply misunderstood production code (not limited to the JDBC code).
You are correct, your description of the problem is vague so I'll try and keep my answers equal as obscure!
First, you need to absolutely positively get a handle on where your production code is, where your test code is, where your production binaries are and where your test binaries are. Don't guess, be 100% certain.
You are not sharing connections between two GUI applications, so that is not your problem. It is possible to share connections between two GUI applications, but it takes a extraordinary coding to succeed and could never be done by mistake or by leaving an application overnight.
If your code does not do an explicit close, I believe in the DB2 environment when your connection is interrupted (terminated unexpectedly) all uncommitted changes are committed (not rolled back). That could be why you don't see the changes until "some time" later. This would point to some horrible coding practice in the production code.
Most applications have the ability to trace and write (log) debug information. If your application has this ability, print out the library into the log (again, make sure we aren't crossing streams here, be 100% certain you know which log is test and which one is production).
I think this may be a coding problem, something with the code lacking appropriate commit or close function. But what I really think from your description is that there is a huge problem with organization of your development environment. The good news is that you have 100% control over the organization and if you properly organize your environment you will have a much easier time figuring this problem out (and your problem may just go away).
Good luck.
# 2
Well, you're definitely right that making sure the test environment is separate is a high priority. I believe this is the only case where I could've messed something up.
It's definitely possible that I HAVE messed something up, because no one else in the office is having any issues with the program...I'm also the only person trying to handle two different instances of the application at once though.
Can we discuss how I should've copied the application to a local drive from the shared drive? I'll explain what I did - maybe that will shed some light on where I went wrong.
1) I copied the whole directory from the shared drive into my workgroup folder for Eclipse on my local drive
2) There exists a batch file that builds the program. Here I changed every path that used to point to the remote directory to point to the local directory. There are some paths in this file that point to the java installation on the remote drive - I left these alone because I wasn't certain that java was even installed on my local drive.
3) I repeated this process on the batch file used for executing the program.
4) Finally, on my local drive, I changed the .properties file to use the new testing library we've set up on the DB2 server.
Other than that I've really done nothing....I haven't modified any code yet at all. I'm tempted to delete my local installation and start over, but I really fail to see how this will solve anything. I don't understand how the local and remote versions of this application can be getting confused based on what I did above. It makes no sense to me how I can modify the regular one (that my co-workers are all using and reporting no problems) and somehow the changes are occurring in the test version. We're all using the exact same batch script to launch the program, so how are these problems only effecting me? This means it HAS to have something to do with my local installation, but honestly I can figure out how.
VP.a at 2007-7-8 23:59:50 >
# 3
> 1) I copied the whole directory from the shared drive
> into my workgroup folder for Eclipse on my local
> drive
Does the whole directory mean that it has source, binaries and properties?
> 2) There exists a batch file that builds the program.
> Here I changed every path that used to point to the
> remote directory to point to the local directory.
> There are some paths in this file that point to the
> java installation on the remote drive - I left these
> alone because I wasn't certain that java was even
> installed on my local drive.
> ) I repeated this process on the batch file used for
> executing the program.
I think you need to install the appropriate SUN JDK onto your local machine to allow you a measure of isolation from the production environment. Once you have done that:
To expedite correcting any organizational issues I would cut the cord by disconnecting the shared drive from your PC. Make the appropriate changes to the (local) properties files to point to the test libraries and run the application from your local machine. Any failures should point to dependencies on the production directory.
To take more control over your environment: Once you have installed the JDK recompile all (local) sources into (local) binaries. This will ensure that you successfully completed ALL the necessary changes in the batch files. Run the application still disconnected from the share drive. Does it work? If it does, then you can be reasonably certain that you have logically isolated your test environment and can re-attach the shared drive (which I抦 sure is shared for good reasons).
All of this will have the added bonus of making you more aware of exactly what your development 揺nvironment?is and how the batch files are doing their work. You will in effect become an expert in the environment and since knowledge is power?br>
> 4) Finally, on my local drive, I changed the
> .properties file to use the new testing library we've
> set up on the DB2 server.
It is possible that the program hard coded a path to the properties file and is using the one on the shared drive. If you cut ties to the shared drive you will find that out. The other thing you could do is change the name of the properties file in the (local) code and recompile it so that it matches a same named properties file on your local drive (I don't really like that option, but since you are struggling...).
> We're all using the
> exact same batch script to launch the program, so how
> are these problems only effecting me?
Again, this is probably just a misunderstanding of the environment. I really think isolating your workstation from the production environment will shine light on where the problem is occurring. There may be other ways to isolate the problem, but this seems like the quickest route to me.
I am making a bit of an assumption that this is the environment and not a coding problem, but from your description it seems the environment is most likely the issue..
# 4
Well, you were right that there was a problem with the environments not being separate...
It turns out that the problem was occurring on the DB2 server. The testing library that we set up was named the same as my username on the DB2 server, and there is a default setting that says the first place the server will try to write to is the library with your username, if it is present. This is why my updates on the production version of the software were ending up in the testing version.
At least your ideas helped me clean up and get a good grasp on my testing environment.
Thanks for your ideas and taking the time to help me resolve this.
VP.a at 2007-7-8 23:59:50 >
# 5
Your'e welcome, I'm glad I helped a little and that you were able to resolve the problem.Best of luck to you.
