Actually, we made a bit of a boo-boo when we designed InsVal() and forgot to
account for NULL values.  I realized this about a week ago and in the new
version the
way this works is that InsVal takes a set of BoundIOs and you can tell the
DBView which columns are NULL from there.  (Alternatively if you are using a
variant_row the default InsVal() function will look at the NULL property and
do this for you.)  The bad news is, the current version doesn't support
writing NULL values.  The good news is, the new version that we hope to
release within another week does.  If you want a sneak preview let us know
and we can send you a beta.

CJ
----- Original Message -----
From: "Cavallin Giovanni (GRTN)" <cavallin.giovanni@...>
To: <cjoy@...>; <michael.gradman@...>
Sent: Wednesday, April 04, 2001 12:30 PM
Subject: How can I insert NULL values?


> I'm just starting to use the DTL library and I'm appreciating it's easy of
> use and support for a clean design in a C++ environment.
> Sometime I have to store records with some unknown field that must appear
as
> a NULL field in the Oracle database.
> How could I do it with DTL ?
> Thank you for your attention.
> Giovanni.
>

Steve,
Thanks for the makefile for an .so.  I have forwarded to the group in case
anyone else needs this.  That's pretty incredible how much smaller the .so
size is.  Regarding the performance overhead of IndexedDBView.  I don't have
any hard numbers on the difference.  I did a few days worth of work
profiling under NT to remove the most egregious errors from DBView but I
still don't have quantative numbers of using one of these iterators versus
raw ODBC calls.  This is still on my to do list to get some hard numbers for
this.

Thanks,

CJ
----- Original Message -----
From: "Steve Frampton" <steve_frampton@...>
To: <cjoy@...>
Sent: Tuesday, April 03, 2001 1:53 AM
Subject: Re: Building the DTL as a shared object library


> Hello:
>
> Corwin Joy <cjoy@...> wrote:
>
> >I have to admit that in the current form of DTL I am sceptical that an
.so
> >would help that much since a lot of the code is still in the headers as
we
> >took
> >a template approach in designining it.
>
> Ah.  I was wondering why the compile times on a very short test program
was
> quite high.  :-)  Anyway, I made a few changes to your Makefile and got
the
> library to build as a shared object.  I stripped it for fun too; the file
> sizes are quite telling:
>
> -rw-rw-r--    1 frampton frampton  2129680 Mar 25 21:05 dtl.a
> -rwxrwxr-x    1 frampton frampton   237052 Apr  3 15:18 libdtl.so
>
> About a 90% reduction in size.  (The dtl.a file shrinks down to 351472
bytes
> when stripped).
>
> Anyway, in case you're interested here is the revised Makefile:
>
> --- begin Makefile ---
> # Define -DMYODBC_BUG to compile with MyODBC/MySQL bug workaround
> DEFS = -DMYODBC_BUG -I.
>
> CC = gcc
> CPPFLAGS = -O0 -g3 $(DEFS)
> OBJECTS = string_util.o date_util.o bind_basics.o DB_Base.o \
>           DBStmt.o DBConnection.o CountedPtr.o BoundIO.o
>
> .cpp.o:
>         $(CC) $(CPPFLAGS) -c $<
>
> all: dtl
>
> dtl: $(OBJECTS)
>         $(CC) $(CPPFLAGS) -shared -o libdtl.so $(OBJECTS)
> --- end Makefile ---
>
> I then modified the Makefile in my test program to include -ldtl as
follows:
>
> LDFLAGS = -lodbc -ldtl
> LIBS =
> $(PROG): $(OBJ) $(LIBS)
>         $(CC) $(CFLAGS) $(LDFLAGS) -o $(PROG) $(OBJ) $(LIBS)
>
> By the way, have you determined what the performance overhead is in using
a
> dynamicindexedview?  (I suppose I should be moving the bulk of my e-mail
> exchanges to the public forums, eh?  Sorry to keep pestering you!)
>
> Cheers...
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>

----- Original Message -----
From: "Corwin Joy" <cjoy@...>
To: "Steve Frampton" <steve_frampton@...>
Cc: <michael.gradman@...>
Sent: Tuesday, April 03, 2001 1:29 AM
Subject: Re: Building the DTL as a shared object library


> Okay, thanks for the link on building shared libraries in RedHat -- that
is good to know.
> I have to admit that in the current form of DTL I am sceptical that an .so
> would
> help that much since a lot of the code is still in the headers as we took
a
> template approach in designining it.  At some point we plan to move more
of
> this into .cpp files which will improve the compile times (shorter
headers)
> and give a more substantial object file to take andvantage of the .so
> architecture you speak of. (Before I do this I need to catch up on my
> reading i.e."Large Scale C++ Software Design,"
> http://cseng.awl.com/book/preface/0,3829,0201633620,00.html ). Even with
> this, bear in mind that since much of this is templated code a lot of it
> does not get built until the first instance of the class, e.g.
> DBView<dataobj> view; // the object will likely get built here for the
first
> time.
>
> There is an interesting discussion on the gcc webpage about where it
stores
> and builds templates - if you really are interested in optimizing you
might
> want to take a look -- plus it's kind of interesting. (GCC "Where's the
> Template?" http://gcc.gnu.org/onlinedocs/gcc_6.html#SEC120)
>
> Thanks again,
>
> CJ
> ----- Original Message -----
> From: "Steve Frampton" <steve_frampton@...>
> To: <cjoy@...>
> Sent: Tuesday, April 03, 2001 12:30 AM
> Subject: Re: Building the DTL as a shared object library
>
>
> > Hello:
> >
> > Corwin Joy <cjoy@...> wrote:
> > >Here I have to admit that I'm prettyr miuch Linux newbie - so I don't
> even
> > >know how
> > >a shared object library works in Linux.  Maybe if you can tell me what
is
> > >involved in building a shared object library I can give you more
> > >information?
> >
> > Okay, I wasn't sure either; I did a quick google search and came up with
> > this link:
> >
> > http://mail.python.org/pipermail/python-list/1999-July/006731.html
> >
> > It might be fairly easy to change the DTL Makefile to build a .so
version
> of
> > your library.  The benefits of doing this means a smaller executable,
less
> > memory usage (ie. if two programs using your library run at the same
time,
> > only one copy of the library needs to be loaded in memory), and probably
> > other benefits.
> >
> > I'll give it a try and let you know...
> >
> > Cheers...
> >
> >
_________________________________________________________________________
> > Get Your Private, Free E-mail from MSN Hotmail at
http://www.hotmail.com.
> >
>

Boris,
	 With a very simple modification (which actually brought up some
interesting and subtle C++ issues in terms of my understanding of the
standard), you can get your code to run without the const_cast.  We should
have included a const version of variant_row::operator[].  Because we
didn't, the compiler could of course would not accept the invocation of  the
non-const version on a const variant_row.  Adding a const version fixed the
problem (which we'll include in the next release) as the compiler sees that
constness is now being enforced properly  All you need to do if you wish to
add the patch yourself is add in the two const overloads of
variant_row::operator[] to variant_row.h.  To do this:

1.  Simply copy and paste in the code from the non-const versions and change
the signatures to:

class variant_row
{
  ...

// return a field by name
const variant_field operator[](const string &f) const;

// return row field by number
const variant_field operator[](int i) const

  ...

};

Note here, that we are still returning by value as we are constructing a
temporary to return and variant_field's are not actually held by the
variant_row class.  Returning a reference would give us a reference to a
trashed temporary (as I found out when playing with this).

2.  In the normal case return statements, const_cast<variant_row *> the
second parameter passed to the variant_field constructor:

const variant_field operator[](const string &f) const
{
....
     // change the line that says: return variant_field(v, this, diff,
IsNull); to
     return variant_field(v, const_cast<variant_row *>(this), diff, IsNull);

...
}

const variant_field operator[](int i) const
{
...

    // change the line that says: return variant_field(variant_t(p,
p_row_fields->types[i]), this, i, IsNull); to
    return variant_field(variant_t(p, p_row_fields->types[i]),
const_cast<variant_row *>(this), i, IsNull);

...
}

This change is needed because the this pointer is const by definition in a
const member function and we need to pass a non-const pointer to the
variant_field constructor.

Note that the logical constness of *this holds.


With those above changes, the constness of variant_row should behave
properly:

*** begin example ***
// modified form of Boris Tursky's example
struct ProcessRecord
{
     void operator()( const variant_row& row )
     {
        // const_cast no longer needed due to new working version
        // of
        // variant_row& row = const_cast< variant_row& >( rrow );

        // some field access
        cout << row[ "INT_VALUE"    ] << ", "
	   << row[ "STRING_VALUE" ] << ", "
	   << row[ "DOUBLE_VALUE" ] << ", "
               << row[ "EXAMPLE_LONG" ] << ", "
	   << row[ "EXAMPLE_DATE" ] << endl;

        // test constness constraint again here
        // should fail to compile

        // due to conversion of preferred conversion
        // of "const variant_field" to "const variant_field &"

        // (interesting sidebar: I thought at first the compiler would try to
convert "const variant_field" to "variant_field".  According to Stroustrop's
Design and Evolution of C++,
       // both conversions are considered "unavoidable" and are what the
compiler will try.  So I went off to the standard.  According to the
standard, in section 13.3.3.1.1,
       // clause 3 (Table 9), the "const variant_field" to
"const_variant_field &" conversion (lvalue to rvalue) has precedence over
the "const variant_field" to "variant_field"
       // (qualification adjustment ... const to non-const) conversion.
Thus, row["INT_VALUE"] will be converted from "const variant_field" to
"const variant_field &".  Of course,
      //  then the compiler will burp as a "const variant_field &" is not a
valid lvalue (or in plain terms, a const violation!))

        // row["INT_VALUE"] = 77;  // surely enough this line doesn't
compile!

        // D:\dtl\tests\example.h(316) : error C2678: binary '=' :
        // no operator defined which takes a left-hand operand of
        // type 'const class dtl::variant_field' (or there is no acceptable
conversion)
     }
};

// Boris Tursky's example test for const variant_row &
void TestVariantRowConstness()
{
	 PrintHeader(cout, "TestVariantRowConstness()");

     DynamicDBView<> view( "DB_EXAMPLE", "*" );
     for_each( view.begin(), view.end(), ProcessRecord() );

	 PrintSeparator(cout);
}

*** end example ***

I'll be at the Association of C/C++ Users Conference at Oxford in the UK
later this week.  Hope to see you there if any of you are going!

Mike

O.K. Let me see if I can answer your questions in order.
1. const version of operator[] for variant_row.
I agree that we probably do need a const version of this operator. Your
const cast should not do anything bad as long as you do not assign back into
the variant_field that you get from operator[].  I will let Mike go into
this in more detail.

2. The NULL issue.
This is a bug.  I messed up when I wrote the DefaultSelValidate function and
forgot to reset the NULL fields.  We'll put out a fix in the next release -
in the meantime here is how you can fix it:
// Change the DefaultSelValidate function for variant_row in DynaDBView.h
line 110 to
template<> class DefaultSelValidate<variant_row> {
public:
  bool operator()(BoundIOs &boundIOs, variant_row &rowbuf)
  {
   rowbuf.ClearNulls(); // <----------------------------- PATCH HERE!
   for (BoundIOs::iterator b_it = boundIOs.begin();
     b_it != boundIOs.end(); b_it++)
   {
    BoundIO &boundIO = (*b_it).second;
    if (boundIO.IsColumn() && boundIO.IsNull())
     rowbuf.SetAsNull(boundIO.GetName()); // found null column ... record
null status in rowbuf
   }

   return true; // assume data is OK
  }
};

// Add a new public member function to the variant_row class
  void ClearNulls() {
   b_IsNull.reset();
  }


3. Performance of DynamicDBView.
The main loss of performance that you have with a DynamicDBView versus a
DBView are two areas:
a.  When the DynamicDBView first constructs it has to query the database to
find out the types of the fields it is reading - this is a bit slower than
knowing this types a priori.
b.  Whenever you assign into a variant row e.g. row["NodeId"] = 5 two
somewhat slow things happen: 1) The variant row has to look up the field
name and construct a variant_field to hold that name.  2) On assignment the
variant_field object does dynamic type checking to see if the value you are
assigning is either of the same type as the target field or can be converted
to the type of the target field before it allows you to assign that value.
So accessing individual fields here is slower than just using a member of a
class -- but hopefully it may not be that bad depending on what you are
trying to do & how often you need to manipulate fields.

That's about it as regards performance, other than that a DynamicDBView
should perform the same as a DBView.

Regards,

CJ

----- Original Message -----
From: "Boris Tursky" <boris_tursky@...>
To: <DatabaseTemplateLibrary@yahoogroups.com>
Sent: Sunday, March 25, 2001 4:04 AM
Subject: [DatabaseTemplateLibrary] operator[] for const variant_row and a
<null> issue


> hi guys!
>
> as i finally have some time, i play with dtl. i found out it is a
> great and fast prototyping tool, especially its dynamic view. three
> lines of code and i have an access to record.
>
> i found another issue. well, seems that this way we'll build solid
> knowledge base soon :-)
>
> i try to use as much of standard algorithms as possible - to separate
> processing of single entity from other level logic - so i tend to
> write a functors. for dynamic view i write one taking const
> variant_row&. howewer, when i try to access fields of this row by
> operator[] , it does not compile, as there is not an operator for
> const variant_row. well, i const_cast and it works. but, is it
> correct here?
>
> VC 6.0 docs say:
> Depending on the type of the referenced object, a write operation
> through the resulting pointer, reference, or pointer to data member
> might produce undefined behavior.
>
> i tried to assign there some value but nothing bad happened. always?
> anyway, is not there a way to write it without the const_cast?
>
> struct ProcessRecord
>    {
>    operator()( const variant_row& rrow )
>       {
>       variant_row& row = const_cast< variant_row& >( rrow );
>       // some field access
>       cdbg << row[ "NodeId" ] << ", "
>          << row[ "ParentNodeId" ] << ", "
>          << row[ "Name" ] << ", "
>          << row[ "Desc" ] << endl;
>       }
>    };
>
> int main( int argc, char* argv[] )
>    {
>    DBConnection::GetDefaultConnection().Connect( "DSN=SomeNodes;" );
>
>    DynamicDBView<> view( "tblNode", "*" );
>    for_each( view.begin(), view.end(), ProcessRecord() );
>
>    return 0;
>    }
>
> ### next issue ###
>
> when i run the code above, it did not work as expected. it printed
> <NULL> for ["ParentNodeId"] in all records, however, there is only
> one <NULL> - in the first record. is it a side effect of my
> const_cast or usage of vatriant_row in my functor?
>
> and when i filter out the record containing null value, everything is
> as expected.
>
> CStdString stWhereClause = "WHERE ParentNodeId IS NOT NULL";
> DynamicDBView<> view( "tblCategory", "*", stWhereClause );
> for_each( view.begin(), view.end(), ProcessRecord() );
>
> ### last question ###
>
> as you can see, i like dynamic view. using db view is a lot of work
> for prototyping, until i do not write some helper for making of all
> the supporting classes. what is the performance difference?
>
> have a nice day,
>
> bt
>
>
>
>
> To unsubscribe from this group, send an email to:
> DatabaseTemplateLibrary-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

hi guys!

as i finally have some time, i play with dtl. i found out it is a
great and fast prototyping tool, especially its dynamic view. three
lines of code and i have an access to record.

i found another issue. well, seems that this way we'll build solid
knowledge base soon :-)

i try to use as much of standard algorithms as possible - to separate
processing of single entity from other level logic - so i tend to
write a functors. for dynamic view i write one taking const
variant_row&. howewer, when i try to access fields of this row by
operator[] , it does not compile, as there is not an operator for
const variant_row. well, i const_cast and it works. but, is it
correct here?

VC 6.0 docs say:
Depending on the type of the referenced object, a write operation
through the resulting pointer, reference, or pointer to data member
might produce undefined behavior.

i tried to assign there some value but nothing bad happened. always?
anyway, is not there a way to write it without the const_cast?

struct ProcessRecord
    {
    operator()( const variant_row& rrow )
       {
       variant_row& row = const_cast< variant_row& >( rrow );
       // some field access
       cdbg << row[ "NodeId" ] << ", "
          << row[ "ParentNodeId" ] << ", "
          << row[ "Name" ] << ", "
          << row[ "Desc" ] << endl;
       }
    };

int main( int argc, char* argv[] )
    {
    DBConnection::GetDefaultConnection().Connect( "DSN=SomeNodes;" );

    DynamicDBView<> view( "tblNode", "*" );
    for_each( view.begin(), view.end(), ProcessRecord() );

    return 0;
    }

### next issue ###

when i run the code above, it did not work as expected. it printed
<NULL> for ["ParentNodeId"] in all records, however, there is only
one <NULL> - in the first record. is it a side effect of my
const_cast or usage of vatriant_row in my functor?

and when i filter out the record containing null value, everything is
as expected.

CStdString stWhereClause = "WHERE ParentNodeId IS NOT NULL";
DynamicDBView<> view( "tblCategory", "*", stWhereClause );
for_each( view.begin(), view.end(), ProcessRecord() );

### last question ###

as you can see, i like dynamic view. using db view is a lot of work
for prototyping, until i do not write some helper for making of all
the supporting classes. what is the performance difference?

have a nice day,

bt

To be honest, we haven't really reviewed the library in detail for thread
safety.
Below is how I would expect it to behave -- but no guarantees since I'm not
an expert at multi-threading and haven't reviewed the library in detail:

1. Static Variables.
We've tried to stay away from static variables as much as possible to make
the classes isolated and thread safe in terms of using only local/stack
variables.  There are two main static variables to be aware of though:
a.  DefaultConnection - is static.
b. The base ODBC environment - is static and allocated upon the first
connection.
c.  We have some date functions in date_util.cpp that foolishly use static
variables when they really shouldn't.  These would also need to be cleaned
up -- this would be easy to do.

2. DBView, DynamicDBView
Each DBView itertor gets its own HSTMT.  So e.g.
DBView::select_iterator it1 = view.begin();
DBView::select_iterator it2 = view.begin();
it3 = i2;
it1, it2 and it3 will all get a seperate HSTMTs.  The underlying ODBC API
should ensure that calls against these seperate HSTMTs will be thread safe
so as long as each thread has its own iterator(s) to work against they
should be safe.

3. IndexedDBView, DynamicIndexedDBView
First off, before these can be thread-safe, the underlying STL library they
are running against needs to be thread safe, e.g. as is done in SGI STL and
STLPort -- see http://www.sgi.com/tech/stl/thread_safety.html

The short version here is that I would expect these containers to be safe
for concurrent reads, but will require mutex locking on the user end to be
safe for concurrent writes/updates/deletes.  ONE IMPORTANT CAVEAT!  The
first time a user attempts to read from an IndexDBView container it will do
a just-in-time fetch to read the underlying data from the database.  This is
not thread safe - so if you want concurrent reads to be thread safe versus a
IndexDBView you will likely want to upgrade the IndexedDBView::fetch()
routine to add a mutex lock e.g.

EnterCriticalSection();
if (bFetched) {
     LeafeCriticalSection();
     return;

... fetch here...

LeaveCriticalSection();

The alternative to changing the dtl code to add a mutex lock would be to
have code manually invoke & lock the fetch() function against any
IndexDBViews it is using.

Corwin


----- Original Message -----
From: "Boris Tursky" <boris_tursky@...>
To: <DatabaseTemplateLibrary@yahoogroups.com>
Sent: Saturday, March 24, 2001 8:01 AM
Subject: [DatabaseTemplateLibrary] multithreading


> Just one more issue:
>
> What about multithreading? Is there some level of thread safety in
> DTL?
>
> (I know, I could find answers to most of my questions in source code,
> but not everyone can and in addition, author can always give a better
> answer, not only "what" but also "why")
>
> bt
>
>
>
> To unsubscribe from this group, send an email to:
> DatabaseTemplateLibrary-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Just one more issue:

What about multithreading? Is there some level of thread safety in
DTL?

(I know, I could find answers to most of my questions in source code,
but not everyone can and in addition, author can always give a better
answer, not only "what" but also "why")

bt

Thanks again, Corwin.

I originally thought it has something to do with optimization, but I
didn't have a time to look for one of them, and there was was too
much of other possibilities, so I gave it up. Debug was enough at a
moment.

bt

Here's the deal. This is some kind of Microsoft compiler bug - I had hoped
it was just my machine but evidently not.  What is happening is that the
Microsoft compiler is ICEing when it tries to generate optimized code for
the release build.  The optimization flag that is causing this is the
"inline function expansion" flag - /Ob1 or /Ob2.  The easy workaround is go
into Project --> Settings-->C++-->Optimizations-->Customize  and choose
"Disable" for inline function expansions.  (Other optimizations such as the
global optimization, 'Favor fast code' and even 'Full optimization' do just
fine).

The other thing that the Microsoft docs say you can do to work around this
compiler bug is to use e.g.
#pragma optimize("b1", off)  // turn off optimizations just for this code
section
#pragma optimize("b2", off)
offending code
#pragma optimize("", on) // restore default optimizations

Unfortunately, I tried doing this for the variant_cc class and it did work.
I think this is because the code fragment
template<typename T> variant_cc_t ( T const& v )
       : data ( new Impl<T>(v) )
       {}

is getting and inlined function from somewhere outside the template code and
then gets confused.

Anyway, the above change will let you do a release build.
Sorry about the Microsoft bug.  Let me know if you have any ideas that can
better isolate this.

Thanks,

Corwin
----- Original Message -----
From: "Darko Hadžija" <Darko.Hadzija@...>
To: <cjoy@...>; <michael.gradman@...>
Sent: Thursday, March 22, 2001 2:34 AM
Subject: Internal compiler error


> Sorry to bother you with this.
> I just downloaded this library (v. 2.01), and tried to build it.
> You can see what I got, when building Your example in release
configuration.
> ...
> --------------------Configuration: example - Win32
> Release--------------------
> Compiling...
> DynamicIndexedViewExample.cpp
> Example.cpp
> ../lib\variant_cc.h(80) : fatal error C1001: INTERNAL COMPILER ERROR
>   (compiler file 'E:\8966\vc98\p2\src\P2\main.c', line 494)
>     Please choose the Technical Support command on the Visual C++
>     Help menu, or open the Technical Support help file for more
information
> ...
> Do I miss something or is it Micro$oft again ?
> ( VS6 + sp5 and NT4 Workstation + sp6 )
>
> Debug build works fine, and Your lib looks also fine at first glance.
>
> Best wishes,
> Darko

Boris,
There are two possibilities for what is happening that come to mind -- see
below:

----- Original Message -----
From: "Boris Tursky" <boris_tursky@...>
To: <DatabaseTemplateLibrary@yahoogroups.com>
Sent: Thursday, March 22, 2001 4:48 AM
Subject: [DatabaseTemplateLibrary] connectiong to data source.. (OT?)


> hello, me again, who else... this group has few topics, so i want to
> help...
>
> I have a strange problem running my simple problem with only
>
> CStdString stDSN = "DSN=LshCfg;";
> dtl::DBConnection::GetDefaultConnection().Connect( stDSN );
>
> and it fails with error
>
> C:\dbs>DataSourceTest.exe
> Exception type: DBException
> Method: DBConnection::Connect(unsigned char *DSN)
> Error Message: Unable to connect to database using DSN
> string "DSN=LshCfg;"!
> SQL Errors:
> (0) SQL Error! SQLSTATE = S1000 Native err = -1028 msg = [Microsoft]
> [ODBC Microsoft Access 97 Driver] Can't open database '(unknown)'. It
> may not be a database that your application recognizes, or the file
> may be corrupt.

This seems to be suggesting that in your ODBC connection setup from the
control panel you did not specify an .mdb file.  However, my guess is that
you were not silly enough to forget this, so I doubt that is the problem.
>
> (1) SQL Error! SQLSTATE = 01000 Native err = 0 msg = [Microsoft][ODBC
> Driver Manager] The driver doesn't support the version of ODBC
> behavior that the application requested (see SQLSetEnvAttr).
>
This is more likely what the problem is.  When we connect, we request that
ODBC return all error codes in the form of ODBC version 3.0 error codes.
So, you will need to make sure that your ODBC driver is version 3.0 or
higher.  In fact, there is very little in our code that cares what ODBC
version it is -- except for the iterator logic.  Here we wanted to be able
to actually interpret the error codes that come back from SQLExecute and
determine if a cursor has gone bad / a row failed etc.  Unfortunately, ODBC
completely changed the codes between version 2.0 and 3.0 so we have to pick
a version of the codes to use so we chose 3.0.  So, check & see what version
of the ODBC library you have installed.

Corwin
>
> ...
>
>
> running on windows embedded nt... i tried many things, on normal nt
> and on my w2k it runs with no problem. i also tried to change version
> back to 97 from 2000, but with no success.. i don't believe it is a
> problem of dtl, or do you do something strange inside? i somehow
> wrote a program with dtl, but did not know the target platform
> before...
>
> bt
>
>
>
> To unsubscribe from this group, send an email to:
> DatabaseTemplateLibrary-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

on some converted databases it works on some not...
bt

hello, me again, who else... this group has few topics, so i want to
help...

I have a strange problem running my simple problem with only

CStdString stDSN = "DSN=LshCfg;";
dtl::DBConnection::GetDefaultConnection().Connect( stDSN );

and it fails with error

C:\dbs>DataSourceTest.exe
Exception type: DBException
Method: DBConnection::Connect(unsigned char *DSN)
Error Message: Unable to connect to database using DSN
string "DSN=LshCfg;"!
SQL Errors:
(0) SQL Error! SQLSTATE = S1000 Native err = -1028 msg = [Microsoft]
[ODBC Microsoft Access 97 Driver] Can't open database '(unknown)'. It
may not be a database that your application recognizes, or the file
may be corrupt.

(1) SQL Error! SQLSTATE = 01000 Native err = 0 msg = [Microsoft][ODBC
Driver Manager] The driver doesn't support the version of ODBC
behavior that the application requested (see SQLSetEnvAttr).


...


running on windows embedded nt... i tried many things, on normal nt
and on my w2k it runs with no problem. i also tried to change version
back to 97 from 2000, but with no success.. i don't believe it is a
problem of dtl, or do you do something strange inside? i somehow
wrote a program with dtl, but did not know the target platform
before...

bt

R:\DTL\lib\variant_cc.h(79) : fatal error C1001: INTERNAL COMPILER
ERROR
   (compiler file 'E:\8799\vc98\p2\src\P2\main.c', line 494)
     Please choose the Technical Support command on the Visual C++
     Help menu, or open the Technical Support help file for more
information
R:\DTL\lib\variant_cc.h(79) : fatal error C1001: INTERNAL COMPILER
ERROR
   (compiler file 'E:\8799\vc98\p2\src\P2\main.c', line 494)
     Please choose the Technical Support command on the Visual C++
     Help menu, or open the Technical Support help file for more
information
Error executing cl.exe.

bt

excellent response, corwin. thank you, i'll try it asap.

bt

----- Original Message -----
From: "Boris Tursky" <boris_tursky@...>


> thank you for reply, corwin.
>
> i asked for something else: if i have some access database, i can
> create query inside it and define parameters inside. so i wanted to
> find out, whether i can set this internal parameters from outside. i
> thought that when in Access Jet SQL reference is PROCEDURE and
> EXECUTE keyword, i could pass this way those internal parameters. not
> sure and i never did it with access that way. i understand reason and
> significance of INSERT, UPDATE, etc, but what about SELECT in
> statement? it is allowed, but what it does? and how it can returns
> records from statement?
>
> have a nice evening, here's morning again :-)
>
> bt
>

It sounds to me like what you are thinking of is a stored proceedure.
So lets say you have a stored proceedure like 'conceptually' this:
// Take an employee name as a parameter and return a department name
VARCHAR GetEmployeeDepartment(VARCHAR EmployeeName) {
     return  SELECT DEPARTMENT FROM EMPLOYEE_TABLE WHERE
NAME = EmployeeName;
}

Now looking in my old "Access 95 Client/Server Development,"  book I see
that: "Access95 defines a stored procedure as One or more SQL statements
that can accept user-declared variables, conditional execution and other
control-flow statements, and that reside on a server.".
So, in Access the above routine would be defined as a stored procedure by
creating a query named GetEmployeeDepartment.

SELECT DEPARTMENT FROM EMPLOYEE_TABLE WHERE
NAME = (?)

The way this would be called from ODBC would be something like this:
SQLExecute("{? = call GetEmployeeDepartment(?)}");
where you would make calls to SQLBindParam to bind two parameters to this
query.  The first parameter would be what is called an 'output' parameter
since values are returned to it (i.e. the department).  The second parameter
would be what is called an 'input' parameter since we send values to it.

So, the question is, how can you invoke a stored proceedure in DTL that
returns a value?
The answer is, you can't.  If you were just passing in parameters you could
kind of do it via a DBStmt e.g.
DBStmt("{call GetEmployeeDepartment("John Smith")}");

To execure stored proceedure and bind return parameters, what we would want
is a new kind of iterator that allows binding of generic parameters to
arbitrary SQL statements.  So, e.g.

generic_iterator<DataObj, ParamObj> it("{? = call
GetEmployeeDepartment(?)}", BCA(), BPA());

*it = ParamObj("", "Employee John Smith"); // set the query paramters
++it; // execute the statement
ParamObj ParamResults = (*it).second; // *it returns a pair <DataObj,
ParamObj>, or perhaps we just have it return a ParamObj and provide a
special accessor for the less frequently used DataObj member

//where you would need to specify a BPA to set the mappings between
parameters & a structure e.g.
BPA(BoundIOs &boundIOs, ParamObj &param) {
     boundIOs[0] == param.Department;
     boundIOs[1] == param.EmployeeName;
     // Would also need some mechanism to specify if each paramter is either
input, output or input/output for the underlying call to SQLBindParam().
Perhaps we could be smart and get the database to tell us?
}

Anyway, what this kind of iterator would let you do is execute an arbitrary
statement repeatedly through an iterator.  E.g.
generic_iterator<DataObj, ParamObj> it("INSERT INTO DB_EXAMPLE VALUES (?, ?,
?)", BCA(), BPA());

generic_iterator<DataObj, ParamObj> it("SELECT NAME, DEPARTMENT FROM
EMPLOYEES WHERE AGE > (?)", BCA(), BPA());

or repeated execution of a stored proceedure as shown above.

This might be kind of fun to write & likely wouldn't be that hard to do.
I'm not sure how many folks would need it though since you only *require* it
in the case of a stored proceedure that returns values.

For now, I leave this as an exercise to the interested reader....

Corwin

thank you for reply, corwin.

i asked for something else: if i have some access database, i can
create query inside it and define parameters inside. so i wanted to
find out, whether i can set this internal parameters from outside. i
thought that when in Access Jet SQL reference is PROCEDURE and
EXECUTE keyword, i could pass this way those internal parameters. not
sure and i never did it with access that way. i understand reason and
significance of INSERT, UPDATE, etc, but what about SELECT in
statement? it is allowed, but what it does? and how it can returns
records from statement?

have a nice evening, here's morning again :-)

bt

--- In DatabaseTemplateLibrary@y..., "Boris Tursky"
<boris_tursky@m...> wrote:
> hi guys,
>
> what about the above? what if i have a parameter in my select query
> in sql server or other odbc database. you write, that i can execute
> execute #ODBC statement, such as INSERT, SELECT, UPDATE or native
SQL
> strings that need to be passed through to the database# (i'm not
> expert in this, so sorry, if it is stupid question...) how can i
> specify it? i also found that you return somewhere some handles, is
> it possible to construct objects from this?
>
> thank you,
>
> bt.

Boris,
I don't really understand what it is you are asking so I guess I'll
just try my best to answer what I think is your question.
Essentially, the DBStmt class allows you to simply pass SQL queries
through to the ODBC SQLExecute() function for processing.  The
statements that you can send to this query can either be ANSI
standard SQL which the ODBC layer will process (e.g. SELECT, INSERT,
UPDATE or DELETE commands).  Or they can be database specific SQL
commands.
Some examples:

// ANSI standard SQL to delete all rows in a table
DBStmt("DELETE FROM DB_EXAMPLE", conn).Execute();

// Oracle specific SQL to delete all rows in a table, gets
passed "straight-through" from the ODBC layer to Oracle.  Will only
work against an Oracle database
DBStmt("TRUNCATE TABLE DB_EXAMPLE", conn).Execute();

// Execute a simple SQL update statement against an employees table,
using ANSI SQL with a parameter that we place in the SQL string when
we compose the query
double AgeParameter = 25;
ostrstream ostrQuery << "UPDATE EMPLOYEES SET SALARY = SALARY + 1000
WHERE AGE  > " << AgeParameter;
DBStmt(ostrQuery.str(), conn).Execute();

Naturally in the case of the Delete or Update statements shown above,
it is often the case that you want to execute many Delete or Update
commands against a given table.  This is where the power of the
delete and update iterators in our library comes into play since
composing a number of SQL statements by hand is tedious.  For some
examples of how this works see the functions UpdateData() and
DeleteData() in Example.cpp in the tests project.  Here we simply
assign to the iterator to set the new values & assign to a Params()
object to set parameters.  This will automatically then generate SQL
for updates like:
Update Table set Field1=(?), F2=(?), ..., FN=(?) where P1= (?) and P2
= (?) ...
which can get quite tedious to do by hand. An even more simple sytax
is provided by the IndexedDBView container where erase(object) will
automatically build a delete statement to delete the row represented
by that object from the database and replace(object) will generate an
update statement.

hi guys,

what about the above? what if i have a parameter in my select query
in sql server or other odbc database. you write, that i can execute
execute #ODBC statement, such as INSERT, SELECT, UPDATE or native SQL
strings that need to be passed through to the database# (i'm not
expert in this, so sorry, if it is stupid question...) how can i
specify it? i also found that you return somewhere some handles, is
it possible to construct objects from this?

thank you,

bt.

ah, here is something similar. so i can send some parameters, but how
will i get recors based on them? (if it is something i should already
know from somewhere else, i'm sorry, i really don't know it)

bt

We've gone ahead and put out a new release.
The main motivation was some minor changes that we needed in order to
run against Microsoft SQL Server.  (We had not gotten around to
testing / supporting MSS prior to this.) Here are the release notes:

Version 2.01
1. Added support for bool data type.
2. Successfully ported code to Microsoft SQL Server.
3. Fixed minor bug with aliased views that did not allow table names
to be aliased in queries.
4. Renamed std_inc.h to std_dtl_inc.h and iterator.h to DB_iterator.h
to avoid filename clashes.
5. Added DBException::GetAllODBCErrors() method.

--- In DatabaseTemplateLibrary@y..., "Boris Tursky"
<boris_tursky@m...> wrote:
> well, it is nice :-)
>
> but what about specifying some parameters? is it possible to use
> dynamic view with a where clause containing a parameter without
> specifying parameter object and bpa?
>
> thank you,
>
> bt

For any DBView or DynamicDBView there are essentially two ways of
specifying a where clause with parameters.  One way is to not set the
parameters until runtime e.g.
"SELECT NAME FROM EMPLOYEES WHERE AGE > (?)"
in this case, if you use the (?) syntax then you need to provide a
parameter object and BPA to supply the parameter value.
e.g.
string strWhereClause = "WHERE AGE > (?)";
DynamicDBView<> view("EMPLOYEE", "NAME", strWhereClause, BPA_AgeParam
());
//then set the age parameter value later using a parameters object


The other way to setup a where clause is to put in the value when you
first build the query string e.g.
"SELECT NAME FROM EMPLOYEES WHERE AGE > 25"

so you might build the where clause as

double AgeParameter = 25;
ostrstream ostrWhereClause << "WHERE AGE > " << AgeParameter << ends;
DynamicDBView<> view("EMPLOYEE", "NAME", ostrWhereClause.str());
// no need for parameter object, parameter set when we built the view

Putting the parameter in a where clause this way is quite
straightforward for all parameter types except dates.  In the case of
dates you will want to call our function Jtime2Timestamp(...) to
write the timestamp structure to a string in the correct ODBC format.

That's it!
CJ

well, it is nice :-)

but what about specifying some parameters? is it possible to use
dynamic view with a where clause containing a parameter without
specifying parameter object and bpa?

thank you,

bt

--- In DatabaseTemplateLibrary@y..., JLee@i... wrote:
> Does DTL support MS SQL DB's?

The underpinnings for the library are plain vanilla ODBC calls, so
DTL should work against anything that supports ODBC 3.0.  As far as
we know, we are not doing anything database dependent and have
checked this versus Access 97, Oracle 7, and MySQL on unix.  So, the
long and short of it is that I would be surprised if it did not run
against SQL Server but I haven't actually done this yet so I can't be
absolutely sure.  Anyway, I hope to give a whirl against SQL Server
in the next few days.  (Just as soon as I finish the painful upgrade
of the machine I have at home from NT workstation to server -- ^&%*
M$! :-) ).

CJ

Does DTL support MS SQL DB's?

We have updated the DTL introduction to include a new 'teaser' / 'show off'
example at the beginning.  Check it out! (

A First Example, Reading and Writing Records in a Table:

As our first example, we show what the code would look like to open a table
and read a set of rows from the database.

////////////////////////////////////////////////////////////////////////////

#include "dtl.h"
using namespace dtl;

// Connect to the database
DBConnection::GetDefaultConnection().Connect(
          "UID=example;PWD=example;DSN=example;"
   );

// Create a container to hold records from a query.
// In this case, the query will be "SELECT * FROM DB_EXAMPLE"
DynamicDBView<> view("DB_EXAMPLE", "*");

// Read all rows from the database and send to cout
copy(view.begin(), view.end(), ostream_iterator<variant_row>(cout, "\n"));

////////////////////////////////////////////////////////////////////////////

P.S. We got spurred on by the corresponding DBTools.h "simple" example that
they use in their advertising.
I think we compare favorably :-)!


Example 1. DBTools.h++ source code
// Select * from table1 (all rows from table1) using DBTools.h++
#include <iostream.h>
#include <rw/db/db.h>
int anInt;
RWCString aString;
float aFloat;
int main ()
{
    RWDBDatabase aDB = // Open the database
        RWDBManager::database("ODBC", "Q+E_paradox", "", "",
        "c:\\paradat");
    RWDBTable aTable = aDB.table("TABLE1"); // Get the table
    RWDBSelector aSelector = aDB.selector(); // Get a selector
       aSelector << aTable; // Specifies SELECT * FROM (every row)
    RWDBReader aReader = aSelector.reader(); // Get a reader, and
    while (aReader()) { // print out each row
       aReader >> anInt >> aString >> aFloat;
       cout << anInt << '\t' << aString << '\t' << aFloat << endl;
    }
    return 0;
}

In general, ODBC lets you do what are known as SQL-pass-through statements
to execute stored proceedures which will then run as native statements
versus the back-end database.  In Oracle, the format for a stored proceedure
looks like this:
" BEGIN STORED_PROCEDURE_NAME(Arg1, Arg2); END; "

so you should be able to submit this via our statement class as

  DBStmt("BEGIN STORED_PROCEDURE_NAME(Arg1, Arg2); END; ", conn).Execute();

which should pass this directly to ODBC for execution.  I'm not sure how
portable the above syntax is across different DBs tho.

Corwin

----- Original Message -----
From: "Peter Morgan" <pmorgan@...>
To: <cjoy@...>; <michael.gradman@...>
Sent: Wednesday, March 14, 2001 5:56 AM
Subject: DTL


> Afternoon,
>
> Firstly - what a great library, an excellent use of the STL. What I would
> like to know is how do you go about calling stored procedures? Is this
> possible with the current library or would an enhancement need to be
made??
> I am only asking this question partly out of ignorance because my
knowledge
> of SQL and relational databases is somewhat limited. Any response would be
> much appreciated.
>
> With Thanks
>
>
> Peter Morgan

Boris,
Thanks for the comments -- they are very helpful to us because
despite over
450 download -- no-one has actually sent us any comments!!
So... let me see if I can respond, in no particular order,
1. I think your comments about the members EXAMPLE_INT and
EXAMPLE_DOUBLE
may be right ... these may be a bit too abstract.  In retrospect a
concrete
example may be better.  It is probably a bit too much of a pain for
us to go
and change this everywhere but we might add a concrete example class
to get
folks started.

2.  I also agree about the bold not being very readable.  Neither
Mike nor I
are really HTML experts so we (naively) just used the html <code> tag
which
doesn't look so hot.  I'm planning on adding a style sheet which
should
clean this up. (DID this March 12th).

As for support - definitely - we're using this internally for a major
project so if you find any bugs that we haven't ferreted out yet we
would
definitely like to hear about them (that was one of our main
incentives for
open source since I think criticism makes things better).

Also, in terms of discussions, since the volume is small for now I was
planning to use the message board on the site (I should label this
better).
If you don't have any objections I would like to post your comments
there
for others to look at if they want.

Thanks again for the comments,

Corwin
----- Original Message -----
From: "Gradman, Michael" <Michael.Gradman@...>
To: <cjoy@...>
Sent: Monday, March 12, 2001 2:39 PM
Subject: FW: select_iterator and for_each (?)


>
>
> -----Original Message-----
> From: Boris Tursky [mailto:boris_tursky@...]
> Sent: Monday, March 12, 2001 2:36 PM
> To: Gradman, Michael
> Subject: Re: select_iterator and for_each (?)
>
>
> Dear Mike,
>
> thank you for your unbelievable fast reply :-) I did not try it
yet, but
it
> looks nice. I was looking forward for v2.0, as it was announced I
looked
at
> the page some 5times a day. I'm not sure, but I think I even
subscribed
your
> notification message and because it did not come, so I was really
surprised
> v2.0 is already released :-)
>
> I have some comments to the example project you mentioned in your
mail and
> to the documentation you provide with library.
>
> example project:
>
> You name the objects something like "INT_VALUE, DOUBLE_VALUE,
examleInt",
> etc, what (imho) is a bit artificial naming and for the first sight
and
> several next tries is a bit obscuring. I think it would help, if
there
were
> some names that would be derived from some real world entities. C++
programs
> are full of ints, longs, examples, etc. and when it is somewhere in
name
of
> object you try to understand or track through code, it is
confusing; it is
> not quite visible because the eye is overloaded with similar words.
Some
> more concrete name from a concrete entity makes it clearer. For me
it is
> much more natural to track a "Person" or "Name" in source code then
> "exampleInt".
>
> documentation:
>
> Very good one, I like that it is in style of SGI STL reference
guide.
> However there are few minor inconsistencies that could be corrected
easily.
> For example:
>
> At the "Introduction to the Database Template Library" page, there
is a
lot
> of code formatted in bold, what is not easily readable. Bold is not
> recommended for large blocks of text and if it is necessary to
highlight
it
> somehow, I would prefer some subtle color adjustment or background.
>
> On the other side, in some reference pages (DBView<DataObj,
> ParamObj>::select_iterator), I noticed there is an example code
without
bold
> style (looks better for me) but not in a monospaced font
>
> Also some columns in tables were too narrow, I think.
>
> Anyway, great work, I understand there is a lot of work creating the
> functional part, this are just minorities, but can be corrected
easily. I
> can help you with it, if you want, but not earlier then after April
1, as
we
> have some time slip in our project and dedicate it all our time.
>
> Boris Tursky

--- In DatabaseTemplateLibrary@y..., "Corwin Joy" <cjoy@h...> wrote:
> <Posted on behalf of Boris Tursky>
> Hello guys!
>
> I downloaded your Database Template Library few days ago. I like it
> very
> much and try it now, but I have a problem forcing select_iterator
to
> work
> with std::for_each algorithm.
>
> I works when I pass view.begin(), but not an initilized
> select_iterator,
> what I need if I want to use parametric SQL query. I noticed that
in
> your
> examples you don't use for_each.
>
> Is it by design, or am I doing something wrong?
>
> BTW, what are your plans with DTL? I see you should release v2.0
> soon,
> do you plan to maintain it? And what about support? I mean some
> newsgroup or mailing list.
>
> Thank you and have a nice day,
>
> Boris Tursky
> Slovakia & Germany
>
>
> *** tear here
> *************************************************************
>
> struct PrintPerson
>  {
>  void operator()( const Person& pers )
>   {
>   TRACE( "%d, %s, %s\n",
>    pers.m_lPersId,
>    pers.m_stFirstName.c_str(),
>    pers.m_stLastName.c_str() );
>   }
>  };
>
>
> typedef DBView< Person, PersonPrm, PersonBCA, PersonBPA >
viewPers_t;
>
> int main( int argc, char* argv[] )
>  {
>  CStdString stDataSource = "UID=login;PWD=pass;DSN=DTL TestData;";
>
>  try
>   {
>   DBConnection::GetDefaultConnection().Connect( stDataSource );
>   viewPers_t viewPers( "qselPers", PersonBCA(), "", PersonBPA() );
>
>   // print ALL records
>   TRACE( "all records:\n" );
>   for_each( viewPers.begin(), viewPers.end(), PrintPerson() );
>
>   // print only selected records
>   viewPers_t::select_iterator si = viewPers.begin();
>   si.Params().m_lPersonId = 1;
>   TRACE( "selected records:\n" );
>   for_each( si, viewPers.end(), PrintPerson() );
>
>
> *** tear here
> *************************************************************

<Posted on behalf of Boris Tursky>
Hello guys!

I downloaded your Database Template Library few days ago. I like it
very
much and try it now, but I have a problem forcing select_iterator to
work
with std::for_each algorithm.

I works when I pass view.begin(), but not an initilized
select_iterator,
what I need if I want to use parametric SQL query. I noticed that in
your
examples you don't use for_each.

Is it by design, or am I doing something wrong?

BTW, what are your plans with DTL? I see you should release v2.0
soon,
do you plan to maintain it? And what about support? I mean some
newsgroup or mailing list.

Thank you and have a nice day,

Boris Tursky
Slovakia & Germany


*** tear here
*************************************************************

struct PrintPerson
  {
  void operator()( const Person& pers )
   {
   TRACE( "%d, %s, %s\n",
    pers.m_lPersId,
    pers.m_stFirstName.c_str(),
    pers.m_stLastName.c_str() );
   }
  };


typedef DBView< Person, PersonPrm, PersonBCA, PersonBPA > viewPers_t;

int main( int argc, char* argv[] )
  {
  CStdString stDataSource = "UID=login;PWD=pass;DSN=DTL TestData;";

  try
   {
   DBConnection::GetDefaultConnection().Connect( stDataSource );
   viewPers_t viewPers( "qselPers", PersonBCA(), "", PersonBPA() );

   // print ALL records
   TRACE( "all records:\n" );
   for_each( viewPers.begin(), viewPers.end(), PrintPerson() );

   // print only selected records
   viewPers_t::select_iterator si = viewPers.begin();
   si.Params().m_lPersonId = 1;
   TRACE( "selected records:\n" );
   for_each( si, viewPers.end(), PrintPerson() );


*** tear here
*************************************************************