RE: [sqlite] SQLite and ODBC
At 1:07 PM -0700 5/17/04, Raymond Irving wrote: Making SQLite more connectable is something that the team should also consider. Not everyone uses C or C++ and not all components have an interface to bind an array. We just have to look at what tools we have available and see how best we can make them integrate-able. A strong point to consider is that, because the SQLite core is written in pure C, it is already in the best situation for integrating or linking, since every other language can bind to C easily, and easy bindings do exist for many languages already. As for C++, consider that a completely different can of worms or language, even if the name also starts with 'C'; C++ is a lot harder to integrate with other languages than C is, but SQLite isn't written in C++, so that's not a concern for most people. -- Darren Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] SQLite and ODBC
Hi, I find I have to agree with the opinion that says keep the ODBC driver should be external to the SQLite source. Why? Well, how many other database engines, client/server or otherwise, come with an ODBC driver embedded with the engine? The answer of course is none. Plenty of vendors supply drivers for all kinds of technologies - JDBC, OLEDB etc but I'm not aware of a single one that embeds the driver with their engine. Surely the beauty of a loosely coupled system is the flexibility afforded to the developer to choose the interface that best suits their needs, whilst still maintaining a small, robust and fast backend. The SQLite download pages are testimony to the enthusiasm of developers for creating SQLite interfaces for a wide variety of languages/environments/platforms. I've used the SQLite ODBC driver in an environment whereby we use SQLite to simulate differing client/server backends and I've found, by and large, that despite the authors caveat about it being experimental, it works really well. Certainly better than the OpenLink driver to Informix which it simulates! Also, I'd rather Richard et al were concentrating their minds on the things I CAN'T do, like improving the engine, rather than wasting their time re-inventing the wheel on things I CAN do... Steve -Original Message- From: Raymond Irving [mailto:[EMAIL PROTECTED] Sent: 17 May 2004 21:08 To: [EMAIL PROTECTED] Subject: RE: [sqlite] SQLite and ODBC Hi, I've download the version at http://www.ch-werner.de/sqliteodbc/ and it works just fine. I was only making a suggestion that such a cool database should come bundled with an ODBC driver (meaning it's part of the development). SQLite is very cool but it does not make any sense if it can't be (easily) integrated with existing components. Rather than having the ODBC driver separate I would suggest that it be a part of the teams plan for future versions. Darren said that this would add more load the the developers but I don't think it should really. Making SQLite more connectable is something that the team should also consider. Not everyone uses C or C++ and not all components have an interface to bind an array. We just have to look at what tools we have available and see how best we can make them integrate-able. __ Raymond Irving "Griggs, Donald" <[EMAIL PROTECTED]> wrote: Regarding: "I was more think of ways to get an SQLite Database connected to every day database objects and controls." A good point! This may be a naive comment of mine, but if you just forgot about the vanilla sqlite download page, and instead considered page: http://www.ch-werner.de/sqliteodbc/ to be THE release point for sqlite-cum-ODBC, would that not give you what you need? [writing for myself, and not on behalf of my company] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] SQLite and ODBC
Hi, I've download the version at http://www.ch-werner.de/sqliteodbc/ and it works just fine. I was only making a suggestion that such a cool database should come bundled with an ODBC driver (meaning it's part of the development). SQLite is very cool but it does not make any sense if it can't be (easily) integrated with existing components. Rather than having the ODBC driver separate I would suggest that it be a part of the teams plan for future versions. Darren said that this would add more load the the developers but I don't think it should really. Making SQLite more connectable is something that the team should also consider. Not everyone uses C or C++ and not all components have an interface to bind an array. We just have to look at what tools we have available and see how best we can make them integrate-able. __ Raymond Irving "Griggs, Donald" <[EMAIL PROTECTED]> wrote: Regarding: "I was more think of ways to get an SQLite Database connected to every day database objects and controls." A good point! This may be a naive comment of mine, but if you just forgot about the vanilla sqlite download page, and instead considered page: http://www.ch-werner.de/sqliteodbc/ to be THE release point for sqlite-cum-ODBC, would that not give you what you need? [writing for myself, and not on behalf of my company]
RE: [sqlite] SQLite and ODBC
Regarding: "I was more think of ways to get an SQLite Database connected to every day database objects and controls." A good point! This may be a naive comment of mine, but if you just forgot about the vanilla sqlite download page, and instead considered page: http://www.ch-werner.de/sqliteodbc/ to be THE release point for sqlite-cum-ODBC, would that not give you what you need? [writing for myself, and not on behalf of my company] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite and ODBC
At 12:29 PM -0700 5/17/04, Raymond Irving wrote: Thanks for the feedback but I was not thinking about network connections to the database. I was more think of ways to get an SQLite Database connected to every day database objects and controls. Most of todays database tools use ODBC. One typical example is how can I (easily) use SQLite inside VB for Databinding? If ODBC was standard then that would be a breeze not only for VB but for the hundreds for Rapid Application Development (RAD) software and components that are available today. Regardless, one or more ODBC drivers are *already* available for SQLite, but are distributed separately. Anyone who wants to use ODBC-dependant development tools with SQlite can download one of those drivers. The fact that a driver isn't bundled with the SQlite core does not preclude its use with ODBC tools. -- Darren Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite and ODBC
Hi, Thanks for the feedback but I was not thinking about network connections to the database. I was more think of ways to get an SQLite Database connected to every day database objects and controls. Most of todays database tools use ODBC. One typical example is how can I (easily) use SQLite inside VB for Databinding? If ODBC was standard then that would be a breeze not only for VB but for the hundreds for Rapid Application Development (RAD) software and components that are available today. __ Raymond Irving Mitchell Vincent <[EMAIL PROTECTED]> wrote: Well put, Darren. Raymond, I would say that if you need ODBC then you need to use a different database (server) all together. SQLite fills the embedded database niche perfectly but it is not a replacement for MS-SQL, MySQl, PostgreSQl, Oracle or other database *servers*. If you need a RDBMS server you are better off using one instead of faking it with SQlite. PostgreSQL and MySQL both run on Windows and are free (well, PostgreSQL is free but who knows about MySQL these days.) Best of luck! Darren Duncan wrote: > At 7:25 AM -0700 5/17/04, Raymond Irving wrote: > >> I think SQLite should come standard with an odbc driver since ODBC is >> an "open standard" > > > I disagree. > > Partly this is because D. Richard Hipp would then have to start > certifying it like his own code and ensuring that it is always up to > date with the core SQLite code, since they would get released together. > That may be more responsibility than he wants. > > Second, SQLite was intended first and foremost for embedding, and for > the large fraction of people that use it that way, a database networking > layer like ODBC is not going to be used anyway. (That said, if SQLite > was intended primarily for a client/server use, then I would more likely > agree with you.) > > The networking code would significantly increase the size of the core > distribution, as well as make it harder to test, as networks have a lot > more variables to be concerned with than a local disk-based system does. > > By keeping the ODBC driver separate, those other people who see that as > their specialty can focus on it on their own time table. Let each > person focus on what they do best, and all that. > > Finally, while ODBC is very common, it isn't the only protocol for > networking databases, and some people may prefer an alternative. > > -- Darren Duncan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite and ODBC
Well put, Darren. Raymond, I would say that if you need ODBC then you need to use a different database (server) all together. SQLite fills the embedded database niche perfectly but it is not a replacement for MS-SQL, MySQl, PostgreSQl, Oracle or other database *servers*. If you need a RDBMS server you are better off using one instead of faking it with SQlite. PostgreSQL and MySQL both run on Windows and are free (well, PostgreSQL is free but who knows about MySQL these days.) Best of luck! Darren Duncan wrote: At 7:25 AM -0700 5/17/04, Raymond Irving wrote: I think SQLite should come standard with an odbc driver since ODBC is an "open standard" I disagree. Partly this is because D. Richard Hipp would then have to start certifying it like his own code and ensuring that it is always up to date with the core SQLite code, since they would get released together. That may be more responsibility than he wants. Second, SQLite was intended first and foremost for embedding, and for the large fraction of people that use it that way, a database networking layer like ODBC is not going to be used anyway. (That said, if SQLite was intended primarily for a client/server use, then I would more likely agree with you.) The networking code would significantly increase the size of the core distribution, as well as make it harder to test, as networks have a lot more variables to be concerned with than a local disk-based system does. By keeping the ODBC driver separate, those other people who see that as their specialty can focus on it on their own time table. Let each person focus on what they do best, and all that. Finally, while ODBC is very common, it isn't the only protocol for networking databases, and some people may prefer an alternative. -- Darren Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite and ODBC
Darren Duncan wrote: At 7:25 AM -0700 5/17/04, Raymond Irving wrote: I think SQLite should come standard with an odbc driver since ODBC is an "open standard" I disagree. .. Finally, while ODBC is very common, it isn't the only protocol for networking databases, and some people may prefer an alternative. I agree with Darren. While ODBC would definitely make my life simpler, it probably better lies upon the SQLite community to create it as an add-on rather than have Richard include it in the core. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite and ODBC
At 7:25 AM -0700 5/17/04, Raymond Irving wrote: I think SQLite should come standard with an odbc driver since ODBC is an "open standard" I disagree. Partly this is because D. Richard Hipp would then have to start certifying it like his own code and ensuring that it is always up to date with the core SQLite code, since they would get released together. That may be more responsibility than he wants. Second, SQLite was intended first and foremost for embedding, and for the large fraction of people that use it that way, a database networking layer like ODBC is not going to be used anyway. (That said, if SQLite was intended primarily for a client/server use, then I would more likely agree with you.) The networking code would significantly increase the size of the core distribution, as well as make it harder to test, as networks have a lot more variables to be concerned with than a local disk-based system does. By keeping the ODBC driver separate, those other people who see that as their specialty can focus on it on their own time table. Let each person focus on what they do best, and all that. Finally, while ODBC is very common, it isn't the only protocol for networking databases, and some people may prefer an alternative. -- Darren Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] SQLite and ODBC/JDBC driver
> -Original Message- > From: Jean-Eric Cuendet [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 06, 2004 6:06 AM > To: [EMAIL PROTECTED] > Subject: [sqlite] SQLite and ODBC/JDBC driver > > There is an ODBC driver here: http://www.ch-werner.de/sqliteodbc/ > But there is no client/server, the server is embedded in the > ODBC driver > on the client. > > I think that we could modify the ODBC driver to communicate through > sockets with the SQLite on the server but that would be a lot > of work.. Sounds like you want an ODBC proxy server. I've not used one but there are some floating around, just "google" for odbc proxy. This one looks interesting http://www.fastflow.it/dbtcp/ SQLRelay can do a similar job (and can connect to ODBC) BUT it does not have an ODBC client api, it has it's own. Chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
