Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2005

Tip: Looking for answers? Try searching our database.

Java PreparedStatements vs ADODB.Command

Thread view: 
Edwinah63 - 23 Nov 2005 03:02 GMT
i am a VB programmer currently learning Java. in VB we can create
command objects which (i think) are equivalent to the Java Prepared
Statement.

HOWEVER, i don't need a connection to create or add parameter values to
an ADODB command object eg: [snippet only]

public function CreateCommand(StringVar as string) as adodb.command

dim cmd as ADODB.Command

cmd = New ADODB.Command

With cmd
   .CommandType = adCmdStoredProc

.CommandText = "MyStoredProc"

 .Parameters.Append(
        .CreateParameter(, adLongVarChar, adParamInput,
Len(StringVar), StringVar) )
end with

'return the object
set CreateCommand = cmd

end function

if i want to execute the command i have just created, i can associate
it with a connection from anywhere in the code eg:

function SomeOtherFunction()

set myCommand = CreateCommand("this is a test only")

with myCommand
 .ActiveConnection = MyConnection
 .execute

end function
***********
Now how do i do the equivalent with Java PreparedStatements?  all the
sample code i can find seems to be like the following:

PreparedStatement ps = myConnection.prepareStatement("{call
MyStoredProc(?)}");
ps.setString(1, StringVar);
ps.execute();

but i want each object to know how to build and return its own
PreparedStatement without respect to any connection object  eg:

public PreparedStatement CreateCommand(StringVar as string)
{
  PreparedStatement ps = new PreparedStatement();

  ps.Where_Do_I_Put_The_SQL_String = "{call MyStoredProc(?)}";

  ps.setString(1, StringVar);

  return ps;
}

public void SomeOtherFunction()
{
//from calling function

PreparedStatement MyPS = CreateCommand("this is a test);

MyPS.Where_Do_I_Put_The_Active_Connection = myConnection();

MyPS.execute();

}

Can it be done? what would be the java equivalent of what i want to do?

many thanks

Edwinah63
Bjorn Abelli - 23 Nov 2005 03:44 GMT
"Edwinah63" wrote...

[snipped legacy code]

> Now how do i do the equivalent with Java PreparedStatements?

From the code below, it rather looks like you want a CallableStatement
instead, as you're working with stored procedures.

> but i want each object to know how to build and return its own
> PreparedStatement without respect to any connection object eg:

Why would you want to ignore the connection?

Anyway, CallableStatement is an interface, so you can't create an instance
of it directly. You'll need some sort of "factory method" for it.

The Connection object provides one for you, so you'll need that first.

I'd guess that there are numerous ways to achieve what you *really* want, as
you haven't shown the necessity to create the statement *before* the
connection...

-------------------------------------------

private void getConnection() {
Connection con = null;
// ToDo: Create a Connection to return...
return con;
}

public CallableStatement CreateCommand
     (Connection con, String stringVar) {
CallableStatement cs =
  con.prepareCall("{call MyStoredProc(?)}");
cs.setString(1, stringVar);
return cs;
}

public void SomeOtherFunction() {
Connection con = getConnection();
CallableStatement myCS =
  CreateCommand(conn, "this is a test");

myCS.execute();

// Do something with the result

myCS.close();
con.close();
}

------------------------------------------
// ...or with the Connection as an instance variable...

Connection con = null;

// Todo: somewhere it's set to a real Connection...

public CallableStatement CreateCommand(String stringVar) {
CallableStatement cs =
  con.prepareCall("{call MyStoredProc(?)}");
cs.setString(1, stringVar);
return cs;
}

public void SomeOtherFunction() {
CallableStatement myCS = CreateCommand("this is a test");
myCS.execute();

// Do something with the result

myCS.close();
}
------------------------------------------

These were just some examples, though I believe it's not the best way to go
about things...

IMHO it's seldom the best way to convert an application from one
platform/language to another by simply changing the "keywords". In that way
you'll probably miss out several constructs in the "new" language, that are
better suited for the task.

But to know that, one has to know more about what the application is
supposed to achieve.

// Bjorn A
Edwinah63 - 23 Nov 2005 04:44 GMT
Hi Bjorn,

many thanks for your reply.  and yes, i think callable statements are
probably more appropriate.

>>Why would you want to ignore the connection?

well, i don't.  i just want to create a callable/prepared statement
that is not associated with a specific connection; this means an object
only needs to know about itself and nothing about the database.

i want all my objects to be completely discreet.

for brevity i'm going to leave out much of the code i would normally
put in so you get the gist:

eg
cPerson
(
  public  Hair_colour as string
  public  Height as int

  public function Createcommand() as adodb.command
     dim cmd as ADODB.Command
     cmd = New ADODB.Command
     With cmd
       .CommandType = adCmdStoredProc
       .CommandText = "UpdateEmp"
       .Parameters.Append( .CreateParameter(, adLongVarChar,
adParamInput, Len(hair_colour), Hair_colour) )
       .Parameters.Append( .CreateParameter(, adInteger,
adParamInput,, Height) )
     end with

   'return the object
   set CreateCommand = cmd
end function

)

function SomeOtherFunction

dim emp as cPerson
set emp = new cPerson

//get values from user
emp.hair_colour = "blonde"
emp.height = 180

//save it to the database
DatabaseManagerObject.Save(emp.createCommand())

DatabaseManagerObject
(

 private function Conn() as adodb.connection   //code to create the
connection

 public function Save(cmd as adodb.command) //save using a command
object
      cmd.activeconnection = Conn
      cmd.execute

     //here is all the error handling to for this kind of transaction
etc

 end function

 public Save(sql as string)  //save via a literal sql string

)

as you can see from the above, i can minimise redundant code, and each
object only needs to do enough to manage itself, nothing more.

>>though I believe it's not the best way to go about things...

i am open to suggestions here, the VB way is not necessarily the Java
way.  now you know what i am trying to achieve, what would be a better
design??

regards

Edwinah63
Edwinah63 - 23 Nov 2005 04:55 GMT
BTW, another version of the DatabaseManagerObject.Save() function could
be:

public function Save(cmd as adodb.command) //save using a command
object

  Conn.begintrans
     cmd.activeconnection = Conn
     cmd.execute

   if err.count = 0 then Conn.commit else Conn.rollback

     //plus all the error handling to for this kind of transaction etc

end function

you get the idea.
Bjorn Abelli - 23 Nov 2005 10:47 GMT
"Edwinah63" wrote...

> i want all my objects to be completely discreet.

So why make them "DB-aware" at all... ;-)

[snipped code]

> i am open to suggestions here, the VB way is not
> necessarily the Java way.  now you know what i am
> trying to achieve, what would be a better design??

Well, there are a lot of options here, as well as opinions on what the best
design really should be, but I'll try to at least give you some quick
pointers. At least they will do about the same thing as you want to, even
though there might be even better designs if you would look at the "whole
picture"...

Anyway, here goes...

import java.sql.*;

// I prefer to separate the Person
// from how to "save" her...

class Person
{
   // I would use setters and getters instead
   // here, but for this example I skip it...
   public String hairColour;
   public int height;
}

// In OOP we use interfaces a lot... ;-)

interface DbObject
{
   void save(Connection conn);
}

// ...so we use that to encapsulate a "real" object
// and make the rest more polymorphic...

class DbPerson implements DbObject
{
   private Person p = null;

   public DbPerson(Person p)
   {
       this.p = p;
   }

   public void save(Connection myConnection)
   {
       CallableStatement cs = null;

       try
       {
           cs =
              myConnection.prepareCall
                ("{call UpdateEmp(?, ?)}");

           cs.setString(1, p.hairColour);
           cs.setInt(2, p.height);

           cs.execute();
           cs.close();
       }
       catch (SQLException sx)
       {
           // Perform error handling here...
       }
   }
}

// I'm not sure how DatabaseManagerObject fits
// into the rest, as this also can depend on other
// considerations, db-wise and others...

class DatabaseManagerObject
{
   private Connection getConnection()
   {
       Connection conn = null;

       // ToDo: Create a Connection...
       // ...or if there's another one
       // as an instance field somewhere...

       return conn;
   }

   // As you see, we only need to know that
   // the object has a method to "save", not
   // what it saves, or how...

   public void save(DbObject dbo)
   {
       try
       {
           Connection conn = getConnection();

           // Now we only have to let the object
           // "save itself"...

           dbo.save(conn);

           // Whether or not you'll close conn here,
           // is rather depending on how the
           // DatabaseManagerObject itself will be
           // constructed, but as this only
           // is an example, we go for that now...

           conn.close();
       }
       catch (SQLException sx)
       {
           // Perform error handling...
       }
   }

   public void save(String sql)
   {
       // Implement an "ordinary" statement
       // handling here...
   }
}

class WhatEver
{
   public void someOtherFunction()
   {
       // To actually know how to construct
       // the DatabaseManagerObject, there
       // are more things to consider,
       // db-wise and others...

       DatabaseManagerObject dbmo =
          new DatabaseManagerObject();

       // ...and possibly the Persons already
       // exist in a list of some sort, but
       // I follow what you did here...

       Person emp = new Person();

       // get values from user...

       emp.hairColour = "blonde";
       emp.height = 180;

       // save it to the database

       dbmo.save(new DbPerson(emp));
   }
}

I hope this helps...

// Bjorn A
Edwinah63 - 30 Nov 2005 00:12 GMT
it most certainly does!!!

the DatabaseManagerObject knows about the database and how to interact
with it, depending on whether it is given a command object or a string
(in this example), but nothing about the object to be saved.

the object to be saved knows about how to generate the command object
or the sql string literal it needs to save itself, but nothing about
the database. this way, i can minimise my code big time.

thank you for taking the time to create the example for me.  vb is not
a true OOP language (tho' vb.net is).

i will take what you have written into my design consideration.

if you know of any good Java object design web pages, please let me
know.

:-)


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.