On 11/26/2011 10:13 PM, Steve Teale wrote:
On Sat, 26 Nov 2011 15:31:33 -0800, bls wrote:
Hi Steve
First of all : I am sorry about my harsh words within my last reply. ---
I am afraid that this feedback is also not very gentle.
Picking up ODBC in order to figure out how an generic database Int
>> As far as I can see db-lib is a dead end for SQL Server - http://
>> msdn.microsoft.com/en-us/library/aa936940%28v=sql.80%29.aspx. ct-lib
>> seems to be a Sybase branch.
>>
>> Steve
>
> I've seen that page as well. I'm wondering if that is about Microsoft's
> implementation. Using Ruby on Rails
On 2011-11-30 18:09, Steve Teale wrote:
As I understand it, FreeTDS provides three client libraries: db-lib,
ct-lib and odbc. These libraries are available as dynamic libraries and
then it won't be any licensing issues.
TinyTDS uses db-lib and it HAS to use dynamic library since it's a Ruby
libr
> As I understand it, FreeTDS provides three client libraries: db-lib,
> ct-lib and odbc. These libraries are available as dynamic libraries and
> then it won't be any licensing issues.
>
> TinyTDS uses db-lib and it HAS to use dynamic library since it's a Ruby
> library. I took a quick look at th
Steve,
Ah, yes, I totally forgot that prepared statements used a better format.
-[Unknown]
On 11/29/2011 9:42 AM, Steve Teale wrote:
On Tue, 29 Nov 2011 09:01:29 -0800, Unknown W. Brackets wrote:
Steve,
The type conversion you talk about (bigint -> double) probably happens
on 32-bit syste
On 2011-11-29 17:21, Steve Teale wrote:
All that said, I think we must still cover ODBC. MS ODBC will be the
official standard interface to SQL Server, and they are doing Linux
versions - the 64 bit one is already available.
Steve
Of course we can still cover ODBC, I just don't think ODBC shou
On Tue, 29 Nov 2011 09:01:29 -0800, Unknown W. Brackets wrote:
> Steve,
>
> The type conversion you talk about (bigint -> double) probably happens
> on 32-bit systems, no? Some of these things will definitely vary
> depending on the database system.
>
> I disagree with him on validation (althou
Steve,
The type conversion you talk about (bigint -> double) probably happens
on 32-bit systems, no? Some of these things will definitely vary
depending on the database system.
I disagree with him on validation (although he's right about
constraints, speaking of atomicy), as others, but I t
>> All that said, I think we must still cover ODBC. MS ODBC will be the
>> official standard interface to SQL Server, and they are doing Linux
>> versions - the 64 bit one is already available.
>>
>> Steve
>
> Of course we can still cover ODBC, I just don't think ODBC should be the
> only, or prim
On Sat, 26 Nov 2011 15:31:33 -0800, bls wrote:
> Picking up ODBC in order to figure out how an generic database Interface
> may look like is a very bad idea.
>
> Creating an ODBC Interface at all is pretty useless. NOBODY is using
> ODBC at all.
Just a point of clarification. It is not my intenti
On 2011-11-29 05:21, Steve Teale wrote:
On Mon, 28 Nov 2011 19:48:37 +0100, Jacob Carlborg wrote:
On 2011-11-28 15:34, Steve Teale wrote:
On Sun, 27 Nov 2011 12:31:32 +0100, Jacob Carlborg wrote:
On 2011-11-27 07:13, Steve Teale wrote:
You may detest ODBC, but it is very soon going to be th
On Mon, 28 Nov 2011 19:48:37 +0100, Jacob Carlborg wrote:
> On 2011-11-28 15:34, Steve Teale wrote:
>> On Sun, 27 Nov 2011 12:31:32 +0100, Jacob Carlborg wrote:
>>
>>> On 2011-11-27 07:13, Steve Teale wrote:
You may detest ODBC, but it is very soon going to be the only way to
communicate
On 2011-11-28 15:34, Steve Teale wrote:
On Sun, 27 Nov 2011 12:31:32 +0100, Jacob Carlborg wrote:
On 2011-11-27 07:13, Steve Teale wrote:
You may detest ODBC, but it is very soon going to be the only way to
communicate with SQL Server short of writing another wire protocol
effort. There was t
On Sun, 27 Nov 2011 12:31:32 +0100, Jacob Carlborg wrote:
> On 2011-11-27 07:13, Steve Teale wrote:
>> You may detest ODBC, but it is very soon going to be the only way to
>> communicate with SQL Server short of writing another wire protocol
>> effort. There was the alternative of OLE DB, but MS
On Sat, 26 Nov 2011 18:31:33 -0500, bls wrote:
Creating std.database based on sockets is useless.
Let's take MySQL for instance. In case that you create a commercial
application based on MySQL you have to pay fees to ORACLE ( approx. 1000
Euro, per Server) and nobody cares about your BOOST
On 2011-11-27 07:13, Steve Teale wrote:
You may detest ODBC, but it is very soon going to be the only way to
communicate with SQL Server short of writing another wire protocol
effort. There was the alternative of OLE DB, but MS is dumping that.
FreeTDS can be used directly.
--
/Jacob Carlborg
bls Wrote:
> Creating an ODBC Interface at all is pretty useless. NOBODY is using
> ODBC at all.
Then why SQLAlchemy supports it?
On Sat, 26 Nov 2011 15:31:33 -0800, bls wrote:
> Hi Steve
> First of all : I am sorry about my harsh words within my last reply. ---
> I am afraid that this feedback is also not very gentle.
>
> Picking up ODBC in order to figure out how an generic database Interface
> may look like is a very bad
bls Wrote:
> Hi Steve
> First of all : I am sorry about my harsh words within my last reply.
> --- I am afraid that this feedback is also not very gentle.
>
> Picking up ODBC in order to figure out how an generic database Interface
> may look like is a very bad idea.
>
> Creating an ODBC Interf
Hi Steve
First of all : I am sorry about my harsh words within my last reply.
--- I am afraid that this feedback is also not very gentle.
Picking up ODBC in order to figure out how an generic database Interface
may look like is a very bad idea.
Creating an ODBC Interface at all is pretty usele
On Thu, 24 Nov 2011 13:09:41 -0500, Kagamin wrote:
>
> It seems this has no connection to columns whatsoever. Whatever data you
> receive from server, it's type is encoded in the received data packet.
> One may want to match types exactly or do sensible conversions like
> round a float to int or p
Sean,
I accidentally deleted your post, and in Pan I don't know how to get it
back.
Yes, most of the API's support that nominal capability, but what they
tell you may not be what you expect, especially with ODBC.
Steve
ODBC provides a means to determine the SQL type of a column in a resultset.
I'll forward my code to you when I get a chance.
Sent from my iPhone
On Nov 24, 2011, at 12:18 AM, Steve Teale wrote:
> This is quite a long exchange relating to ODBC and SQL Server, but I'd
> like the opinion of the
Steve Teale Wrote:
> The cases I am moaning about are when I ask for say an eight byte integer
> from a column that is defined as one, and get back a double-precision
> floating point - a format not even capable of holding the value. If the
> server can't return one of the types it supports via
On 2011-11-24 09:18, Steve Teale wrote:
This is quite a long exchange relating to ODBC and SQL Server, but I'd
like the opinion of the D community on it. Am I being unreasonable?
On Wed, 2011-11-23 at 18:11 -0500, James K. Lowden wrote:
I've written two C++ database interface libraries. I don'
This is quite a long exchange relating to ODBC and SQL Server, but I'd
like the opinion of the D community on it. Am I being unreasonable?
On Wed, 2011-11-23 at 18:11 -0500, James K. Lowden wrote:
I've written two C++ database interface libraries. I don't understand
> why you want to know what
26 matches
Mail list logo
