You should not have any problems with ODBC on Windows regarding
licensing, I imagine.
After all you just need to code against the Win32 ODBC API. You
don't need to consider the real driver you are talking with.
--
Paulo
On 10.11.2011 18:54, Steve Teale wrote:
I have pushed a first cut of the n
I have pushed a first cut of the native MySQL driver to
https://github.com/britseye
The documentation can be seen at
britseyeview.com/software/mysqln/
I'm now investigating ODBC. That should be a fairly quick exercise, since
I have already done ODBCD once, and I'm just doing a sketch at this
Le 05/11/2011 17:37, Steve Teale a écrit :
> On Sat, 05 Nov 2011 09:34:34 +0100, Somedude wrote:
> What I'm working on at the moment is the MySQL driver. That does as you
> note have the LIMIT clause so I had no need to do anything special.
>
> I have provided the capability to map rows to a stru
On 11/05/2011 10:23 AM, Sean Kelly wrote:
Is it possible to listen on multiple events with a single connection?
Sure, it is possible. see my code snippet.
On Nov 5, 2011, at 4:29 AM, Dejan Lekic wrote:
> On Fri, 04 Nov 2011 15:00:17 -0700, Sean Kelly wrote:
>
>> notification isn't typically done via a back-feed through a client
>> connection. Do any modern DBMSes have pub/sub functionality like this?
>
> Ingres, for an instance, has the DBEVENT,
On Sat, 05 Nov 2011 09:34:34 +0100, Somedude wrote:
>
> A few simple questions/requests:
> 1. Does your library allow to get the resultset by batch of N rows ?
> It's a common requirement for databases that don't have the equivalent
> of the LIMIT clause of MySQL like Oracle. In those DBs, one has
On Fri, 04 Nov 2011 15:00:17 -0700, Sean Kelly wrote:
> notification isn't typically done via a back-feed through a client
> connection. Do any modern DBMSes have pub/sub functionality like this?
Ingres, for an instance, has the DBEVENT, and it is possible to create/
handle it via JDBC, ODBC, .N
On 11/04/2011 03:00 PM, Sean Kelly wrote:
nless something has changed in the last few years, the way to do this in MSSQL
is via a plugin in the SQL server itself. Back in the days of yore this was
via extended stored procedures, which were loaded as a DLL by the SQL server,
but I think more r
Le 04/11/2011 06:15, Steve Teale a écrit :
> I'm getting pretty close to having a reasonably comprehensive native D
> driver for MySQL - no translated header files, no linking to libraries.
> ...
> Steve
A few simple questions/requests:
1. Does your library allow to get the resultset by batch of
On Nov 4, 2011, at 12:05 PM, Steve Teale wrote:
> On Fri, 04 Nov 2011 10:19:23 -0700, bls wrote:
>
>> On 11/04/2011 09:25 AM, Steve Teale wrote:
>>> I don't think you need to worry
>>> about changes while stepping through rows.
>>
>
> As in don't worry about something over which you have no co
On Fri, 04 Nov 2011 16:58:23 +, Dejan Lekic wrote:
>
> It is all right - you asked for opinions - you got it. :)
>
> If I wanted to do it in chunks, I would code that myself, and execute
> something like "SELECT * FROM few_bil_rows_table LIMIT offset,
> rowCount".
That's close to my point. S
On 11/04/2011 12:05 PM, Steve Teale wrote:
Your point is in fact in support of what I was saying. Why the hell allow
the user to get 2^^64 rows when they're going to be out of date before
they've been got together!
Exactly. That's why we prefer server side events and refresh the
UI/RowSet just
On Fri, 04 Nov 2011 10:19:23 -0700, bls wrote:
> On 11/04/2011 09:25 AM, Steve Teale wrote:
>> I don't think you need to worry
>> about changes while stepping through rows.
>
As in don't worry about something over which you have no control!
> However, there are always many ways to skin a cat.
On 11/04/2011 09:25 AM, Steve Teale wrote:
I don't think you need to worry
about changes while stepping through rows.
That's questionable. Consider Stock Market quotes. Some lib designers,
for instance. libpgxx (C++ PostgreSQL) have a different view.. let me
quote :
*With conventional datab
Steve Teale wrote:
>
> Don't get me wrong. I was not asking if it should be possible to get a
> complete result set, only if we needed to support sets with 2^^64 rows on
> a 32 bit system. Personally I think that is close to stupid - SQL is
> supposed to allow you to select the rows you want - no
On Fri, 04 Nov 2011 15:04:39 +, Dejan Lekic wrote:
>
> Yes it is. It is a common practice to get the whole thing rather than to
> take it in chunks. (Atomically so to speak) 1) The first thing that
> comes to mind is efficiency. 2) The second is - you remove the
> complexity (you will have to
Steve Teale wrote:
>
> I also have a question. MySQL potentially produces result sets of up to
> 64 bit size - rows. The MySQL client theoretically copes with these by
> storing a result set as a doubly linked list, and there's nothing to stop
> me doing the same. But is it necessary?
Yes it is.
On Fri, 04 Nov 2011 12:13:34 +0100, Piotr Szturmaj wrote:
>
> Why not return a range, that will fetch next row when needed? popFront()
> will call socket's recv, parse and then store that row for the front()
> calls. This may be internally buffered to 100 rows or so.
>
> Example: https://github.c
I also have a question. MySQL potentially produces result sets of up to
64 bit size - rows. The MySQL client theoretically copes with these by
storing a result set as a doubly linked list, and there's nothing to stop
me doing the same. But is it necessary?
Why not return a range, that will fetch
On 11/03/2011 10:15 PM, Steve Teale wrote:
2) No Windows Named Pipe support that I've noticed.
Isn't it part of std.windows ? Named piped support is part of
kernel32.dll maybe this link helps >
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365150(v=vs.85).aspx
3) No SHA1 diges
On Nov 3, 2011, at 10:15 PM, Steve Teale wrote:
>
> I also have a question. MySQL potentially produces result sets of up to
> 64 bit size - rows. The MySQL client theoretically copes with these by
> storing a result set as a doubly linked list, and there's nothing to stop
> me doing the same. B
> 1) No UNIX Socket support in std.socket.
Someone has added unix domain sockets in one of the phobos forks. I even
think there's a pending pull request.
I'm getting pretty close to having a reasonably comprehensive native D
driver for MySQL - no translated header files, no linking to libraries.
However there are three blocking factors, features missing in Phobos that
would stop it's use as things stand.
1) No UNIX Socket support in std.socket.
23 matches
Mail list logo
