light weight, stand alone data solution
BobF
desktop MFC app.
A few thousand records total in a small number of tables. So far I've
looked at SQLite and mdb files.
It doesn't look like there's any direct support for MFC with SQLite.
I'm trying to avoid having to support db server installation and such.
Any other ideas?
Goran
> It doesn't look like there's any direct support for MFC with SQLite.
SO WHAT? It's a library. Call functions.
The nerve of some people...
Goran.
BobF
Yes, what nerve. I may actually want to plug in a real database some
day ...
Goran
Well, do you want a "real" database or not, then? (General tone of
your first post and e.g. "I'm trying to avoid having to support db
server installation and such" pretty much says you don't.)
But still, bad question. MFC in itself does not support any database
library. So you don't want "MFC" support, you want ODBC or JET
support.
Perhaps you could see what "Extensible Storage Engine" could do for
you. http://msdn.microsoft.com/en-us/library/ms684493%28EXCHG.10%29.aspx.
It seems it works with JET, and MFC, too.
Goran.
Joseph M. Newcomer
wow, the complexity boggles the imagination...
Has it occured to you that you can encapsulate the abstractions in subroutines? One
subroutine contains a sequence of SQLite calls, and next year it issues SQL queries?
Or is the concept of abstraction too, well, abstract?
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
BobF
> On Oct 30, 1:44 pm, BobF <notha...@no.spam> wrote:
>> Goran wrote:
>>> On Oct 30, 11:56 am, BobF <notha...@no.spam> wrote:
>>>> It doesn't look like there's any direct support for MFC with SQLite.
>>> SO WHAT? It's a library. Call functions.
>>> The nerve of some people...
>>> Goran.
>> Yes, what nerve. I may actually want to plug in a real database some
>> day ...
>
> Well, do you want a "real" database or not, then? (General tone of
> your first post and e.g. "I'm trying to avoid having to support db
> server installation and such" pretty much says you don't.)
>
> But still, bad question. MFC in itself does not support any database
> library. So you don't want "MFC" support, you want ODBC or JET
> support.
Yes, you are correct. I shouldn't have said "MFC" support. I should
have specified ODBC, OLE DB, etc.
>
> Perhaps you could see what "Extensible Storage Engine" could do for
> you. http://msdn.microsoft.com/en-us/library/ms684493%28EXCHG.10%29.aspx.
> It seems it works with JET, and MFC, too.
>
> Goran.
Ahhhh, finally. Something helpful. Thanks
BobF
> Duh.
Still the same old Joe I see ...
> And exactly how will you plug in a "real database"? Hmmm...by calling functions! Oh
> wow, the complexity boggles the imagination...
Hmmmm, I guess it's hard to think in anything other than literals with
the lack of fresh air and light where your head apparently is right now.
I would "plug in" a real database by replacing the light-weight solution
with a 'real' engine. The goal being to start out in such a way as to
minimize the effort (re-write) required to do that.
>
> Has it occured to you that you can encapsulate the abstractions in subroutines?
Gee, nope. The thought never occurred to me! Geeeezzzzzz ...
Are you telling me that you never take into consideration the idea of
making those little rewrites easier in the future?
> One
> subroutine contains a sequence of SQLite calls, and next year it issues SQL queries?
Joe, I've read and admired your contributions here for many years. You
didn't earn that respect by stating the obvious.
Of course code will have to change when the data provider changes. That
doesn't mean I shouldn't consider as simple as possible migration path
up front.
>
> Or is the concept of abstraction too, well, abstract?
Are the insults and condescension really necessary?
If these are necessary, then I'm sure I could come up with a few myself.
Do you think that would make for a productive exchange of ideas?
David Crow
approach, but your response in this thread is borderline rude.
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:3fsle5tlbsr1fualm...@4ax.com...
Mikep
"BobF" <noth...@no.spam> wrote in message
news:%23gSkD%23UWKH...@TK2MSFTNGP02.phx.gbl...
How about an ADO interface sitting on top of an xml/xsd file - you get one
file for a datbase that can contain multiple datatables. You can start ny
looking at DataSet.ReadXml.
The DataSet and its tables can be designed in Visual Studio using the
DataSet editor.
M
BobF
Thanks Mike, I'll check it out. I'm looking over MFC DAO ... looks
promising so far.
Joseph M. Newcomer
seemed obvious. But then the response was "but this will prevent my plugging a real
database in". It seemed screamingly obvious that to minimize future rewrites, the
solution would be to create a subroutine that provided the necessary abstractions. Instead
of issuing a SQL request, just call the necessary subroutines to interface to the
database.
I did database programming from 1984 through 1997, and stopped when the database
technology got too expensive to use (SQL, Oracle). I have barely touched it since.
I've done this several times to abstract database access from database implementation, and
in one case we just replugged SQL commands in a few years later. I didn't do it, but the
client said that it took only a couple days to make the conversion, because we had planned
on this when the code was written. So it is possible, and it wasn't even very hard. We
once converted a dBASE interface to a Paradox interface in a couple days, maintaining
common source depending on the customers' needs. If I'd had DLLs (this was in MS-DOS), I
would have simply created DLLs with the appropriate interfaces and we could have supplied
the DLL of choice to the customers (we did two different builds, instead).
The most recent one was an MS-DOS program converted to a Windows app, around 2000 or 2001.
What we did was write the SQL command as a comment (the client did this, I'm not a SQL
programmer), and I wrote a subroutine that implemented the SQL command by doing subroutine
calls. So when time came to update (which we anticipated) the entire body of the function
became a SQL call of the SQL command of the comment. I implemented an abstract notion of
"recordset" and the "get next record from recordset" call took a pointer to an object and
returned the data of the next record. Obviously this was trivial to change. I haven't
seen the current code, but mostly the change consisted of excising the clumsier code
required for the database library we were using (a dBASE IV-compatible library, and we
knew the database implementation was going to have a limited lifetime, which turned out to
be about five years).
So it is doable, and trivially, and it is obvious how to do it. Writing a subroutine is
not Rocket Science. The OP seemed to think that it was. I expect programmers to have a
minimum understanding of their profession, even if the complexities and subtleties of
particular APIs, MFC classes, VS idiosyncracies, etc. prompt detailed questions. The
response indicated a lack of this ability to reason about programming. I get tired of
people wanting solutions handed to them. Perhaps it is because I just taught a course in
which half the students were unable to do anything other than retype what I put on my
slides, and failed completely to reason about even the most elementary concepts of code
refactorization, abstraction, or generalization, that has left me disappointed with the
current state of programming education. (Simple example: I show an example with variable
names a, b, c; the students have typed in code that uses names x, y, and z, and then to
integrate the code from the slide, fail to see how the names in my code correspond to the
names in their code; instead, they use a, b and c and wonder why the names are undefined.
One even wrote variable declarations for them, then wondered why the (uninitialized)
variables didn't work!) I'm in the middle of converting a piece of code that would have
failed Introduction To C 101, and has taken days of effort just to rewrite to something
approximating Acceptable Practice (not even Best Practice; the client can't afford that!)
I'm tired of dealing with people who can't manage the obviously elementary skills of
programming. This is not Windows programming, it is not MFC programming, it is
really-basic-how-do-you-do-abstraction, something that everyone should understand how to
do.
joe
David Ching
SQLite would be my first choice also. But also check out MS SQL Server
Compact: http://www.microsoft.com/Sqlserver/2005/en/us/compact.aspx
Drawback is that has a COM interface.
-- David
BobF
Thanks. I'll check it out.
David Ching
> It was a silly response to a reasonable answer. The answer was "call
> subroutines", which
> seemed obvious. But then the response was "but this will prevent my
> plugging a real
> database in". It seemed screamingly obvious that to minimize future
> rewrites, the
> solution would be to create a subroutine that provided the necessary
> abstractions. Instead
> of issuing a SQL request, just call the necessary subroutines to interface
> to the
> database.
>
It seems that someone should be applauded for wanting to write once to SQL
and later take advantage of SQL's ability to swap out engines underneath.
The example of converting from dBase to Paradox is so old fashioned. Why do
that when there is *zero* rewrite if one takes advantage of modern database
architecture?
-- David
David Ching
> I'm looking over MFC DAO ... looks promising so far.
I believe ADO is the newer interface and offers better performance than DAO
(which I believe rely on very old ODBC).
-- David
Anthony Wieser
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:uCFT2zZW...@TK2MSFTNGP05.phx.gbl...
I've had good luck using the ATL OLEDB templates, and SQL server CE 3.5 SP1.
I note SP2 is now out too in beta.
It's in process, and has a relatively small installer. There's also a .NET
set of classes as well.
Anthony Wieser
Wieser Software Ltd
BobF
I see that. Problem is that ADO doesn't support DDL (or it didn't).
It doesn't matter though. SSCE is exactly the solution I was looking
for. I don't know why I've never *noticed* it before.
Thanks again for pointing it out to me!
BobF
>
> I've had good luck using the ATL OLEDB templates, and SQL server CE 3.5
> SP1.
> I note SP2 is now out too in beta.
>
> It's in process, and has a relatively small installer. There's also a
> .NET set of classes as well.
>
> Anthony Wieser
> Wieser Software Ltd
>
Andy - thanks for the recommendation. I think this is the direction
I'll go.
David Ching
> I see that. Problem is that ADO doesn't support DDL (or it didn't).
>
What is DDL? ADO is what is used in .NET so I'm surprised to hear it
doesn't support something! ;)
> It doesn't matter though. SSCE is exactly the solution I was looking for.
> I don't know why I've never *noticed* it before.
>
> Thanks again for pointing it out to me!
>
My pleasure.
-- David
Jonathan Wood
use an existing wrapper. If you want an interface where the functionality
could later be swapped out, create or use an existing wrapper. And if you
want a solution that provides a specific type of interface or allows you to
swap specific components out, then perhaps that would be a good thing to put
in your question over just saying you want a data storage solution.
"BobF" <noth...@no.spam> wrote in message
news:#gSkD#UWKHA...@TK2MSFTNGP02.phx.gbl...
--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
Giovanni Dicanio
"Anthony Wieser" <newsgroup...@wieser-software.com> ha scritto nel
messaggio news:OxBFEYbW...@TK2MSFTNGP04.phx.gbl...
> I've had good luck using the ATL OLEDB templates, and SQL server CE 3.5
> SP1.
To support the choice of SQL Server Compact Edition: this component is used
also to build the new IntelliSense engine in VS2010:
http://blogs.msdn.com/vcblog/archive/2009/05/27/rebuilding-intellisense.aspx
Giovanni
BobF
> I was very happy with SQLite. If you don't want to call functions,
> create or use an existing wrapper. If you want an interface where the
> functionality could later be swapped out, create or use an existing
> wrapper. And if you want a solution that provides a specific type of
> interface or allows you to swap specific components out, then perhaps
> that would be a good thing to put in your question over just saying you
> want a data storage solution.
You're right. It would have been better. However, the thought didn't
really occur to me until I looked under the SQLite hood a little bit.
BobF
Thanx.
BobF
> "BobF" <noth...@no.spam> wrote in message
> news:eQZtrCcW...@TK2MSFTNGP04.phx.gbl...
>> I see that. Problem is that ADO doesn't support DDL (or it didn't).
>>
>
> What is DDL? ADO is what is used in .NET so I'm surprised to hear it
> doesn't support something! ;)
Data Definition Language - the ability to create/alter database. If ADO
has been updated to allow this, it still requires that the database be
created from within the application.
SQL Server Mgmt Studio is a good place to create the database, tables
and such for SSCE. I much prefer to build the front end separately from
the database itself. This is more in line with the way I've worked with
databases in the past.
David Ching
> Data Definition Language - the ability to create/alter database. If ADO
> has been updated to allow this, it still requires that the database be
> created from within the application.
>
> SQL Server Mgmt Studio is a good place to create the database, tables and
> such for SSCE. I much prefer to build the front end separately from the
> database itself. This is more in line with the way I've worked with
> databases in the past.
>
I've never done it, but isn't there a CREATE SQL command similar to SELECT
that lets you use standard SQL to create a database table? Like you, I just
create the table and edit/edit columns using Management Studio, then access
the database with ADO. So whether or not ADO does support DDL, it really
doesn't matter to either of us?
-- David
BobF
> "BobF" <noth...@no.spam> wrote in message
> news:epWfPbjW...@TK2MSFTNGP02.phx.gbl...
>> Data Definition Language - the ability to create/alter database. If
>> ADO has been updated to allow this, it still requires that the
>> database be created from within the application.
>>
>> SQL Server Mgmt Studio is a good place to create the database, tables
>> and such for SSCE. I much prefer to build the front end separately
>> from the database itself. This is more in line with the way I've
>> worked with databases in the past.
>>
>
> I've never done it, but isn't there a CREATE SQL command similar to
> SELECT that lets you use standard SQL to create a database table?
Yep. SQL contains those commands. There just isn't always full support
for them.
> Like
> you, I just create the table and edit/edit columns using Management
> Studio, then access the database with ADO. So whether or not ADO does
> support DDL, it really doesn't matter to either of us?
>
> -- David
>
>
No, it doesn't matter with SSCE b/c Mgmt Studio provides the means to
maintain the db structure.
I'm a happy camper.
Joseph M. Newcomer
want to use SQL in the future" does not preclude the use of a lightweight library today.
We knew when we converted the MS-DOS program that we wanted to use a "real" database
system in the future, so we planned on it. Instead of calling the lightweight library
directly, we wrote the SQL we wanted to write (someone else wrote it for me). Then I
wrote a function that did it, using the lightweight library. Years later, we replaced the
bodies of these functions with a SQL call and none of the callers noticed the difference,
because they didn't care how the implementation worked. This is a pretty obvious solution
if you think about it for more than a couple milliseconds.
In those days, SQL Server cost several thousand dollars and was not something that could
be imposed on their customers. Once SQL became a standard interface, and Personal SQL
Server was ubiquitous, we upgraded the code with minimal effort, ripping out the bodies of
the functions and replacing them with SQL queries. The remaining 98% of the code never
noticed (it was > 95% of the code that was unrelated to the database access. We were
doing some pretty heavy things to that data).
My objection was that the OP failed to see the obvious upgrade solution: abstract the
operations, write an implementation of the abstraction, then replace the implementation
with a different implementation in the future.
joe
BobF
Joseph M. Newcomer wrote:
>
> My objection was that the OP failed to see the obvious upgrade solution: abstract the
> operations, write an implementation of the abstraction, then replace the implementation
> with a different implementation in the future.
> joe
I didn't fail to 'see' or understand what was suggested. I chose to
continue looking for something that would require replacing less in the
future.
The first suggestion isn't always the best.
Victor
Well, but ADOX does it!
Victor
"BobF" <noth...@no.spam> wrote in message
news:eQZtrCcW...@TK2MSFTNGP04.phx.gbl...
BobF
Thanks, Victor ... I found ADOX a while ago. But ...
"It doesn't matter though. SSCE is exactly the solution I was looking
for. I don't know why I've never *noticed* it before."
I'm using vs2005 w/ssce2005. The integration with vs is excellent.
I've also decided to go with c# for this project. Very smooth and
straight-forward.
David Ching
> No, it doesn't matter with SSCE b/c Mgmt Studio provides the means to
> maintain the db structure.
>
> I'm a happy camper.
BTW, you will be even happier if you ditch Management Studio and just use
Server Explorer in Visual Studio!
-- David
BobF
Already done!!