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 should be the
>> only, or primary, interface to SQL Server.
>
> But in that case we should do a D TDS version to escape from any
> licensing/linking limitations. That won't happen tomorrow ;=)

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 the source code for TinyTDS, it's quite a small library.

http://www.freetds.org/which_api.html

-- 
/Jacob Carlborg

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 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 think that's not
>> what you're after.
>>
>> You just want to know the types of the result fields, right?  I don't
>> know this specifically for ODBC/SQL Server, but it may be worth pointing
>> out that MySQL sends everything as strings:
>>
> It is sorted now. I was using a version of TDS provided by the Ubuntu
> package management system that turned out to be hopelessly out of date.
> I've built it now from FreeTDS CVS, and it works OK.
>
> MySQL 5 returns data from plain old ExecSQL as strings, but for prepared
> statements it uses a binary format. However I have no problems with type
> determination there.
>
> Thanks for taking the trouble to help.
>
> Steve

> 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 the source code for TinyTDS, it's quite a small library.
> 
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

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
>> library. I took a quick look at the source code for TinyTDS, it's quite
>> a small library.
>>
> 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, TinyTDS is the preferred way of connecting to SQL Server these days. We're successfully using it at work to connect to SQL Server 2007.

-- 
/Jacob Carlborg

>> 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, TinyTDS is the preferred way of connecting to SQL Server these days. We're successfully using it at work to connect to SQL Server 2007.

Well yes that could well be the case. As long as they are still using TDS, whatever is on the other side of that is a black box as far as they are concerned. I'll take a look at it as soon as I am on top of the ODBC implementation.

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 Interface
>> may look like is a very bad idea.
>>
>> Creating an ODBC Interface at all is pretty useless. NOBODY is using
>> ODBC at all.
>>
>> 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 licensed Phobos raw socket stuff..
>>
>> Despite that : std.database becomes unmaintainable. I've had a look at
>> your sources, Tough stuff.  Same is valid Piotr's PostgreSQL
>> implementation.
>>
>> NO!.
>> I am all against it. I think that implementing std.database requires
>> understanding of Martin Fowler's  Enterprise patterns, As said before :
>> Function follows Form  :)
>>
>> Last, and most probably useless comment, Have a look at
>> http://www.sqlalchemy.org/
>>
>> Cheers,
>> Bjoern
>
> Bjoern,
>
> No need for apologies, the D newsgroup is a hard school.
>
> The intro for SQLAlchemy says:
>
> "Over five years of constant development, profiling, and refactoring has
> led to a toolkit that is high performing and accurate, well covered in
> tests, and deployed in thousands of environments."
>
> The situation for D is probably roughly as follows:
>
> "About three months  of experimentation, and struggle with inaccurate
> documentation, has led to a point where a group of three or four of us
> can communicate reasonably effectively with four database systems - MySQL
> (API and Protocol), SQLite, PostgreSQL (API and Protocol), and SQL Server
> (from Linux and from Windows vis ODBC).
>
> We are learning to walk. To do the things SQLAlchemy describes, I think
> you have to understand how to do that.
>
> 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.
>
> In another post under the std.database thread I have already suggested
> that the post of top-down high level designer is certainly up for grabs.
> Do you fancy it? Maybe by the time the top level design is completed,
> Piotr and I and and others will have the means to do the nitty-gritty
> lower-level stuff. in a reasonably consistent way.
>
> Steve

Point taken! Thanks. :)
Despite that....  hope you will agree with me that following/mimic JDBC instead of ODBC makes more sense.

Sure, it's your turn and  ..
asinus sacuum portat.

so I'd better shut up.
Bjoern