Hi,

Looking at the FPC 2.6.4 fcl-db source folder it seems that SqlDB does have MS SQL Server support. What confuses me is that the readme.txt files mentions that I must download FreeTDS sources and compile it with MS Visual C++ (a compiler I don't have and have never used).

Could somebody explain the situation with SqlDB and MS SQL Server support?

* Must I have C++ compiler
* Is the MS SQL Server support any good?
* What version of MS SQL Server is supported?

The program I am writing is going to run on the server which hosts SQL Server, so client libraries should all be there. Do I still need this FreeTDS library mentioned?

Is FPC 2.7.1 support any better - I could use that if I must.

While I'm at it, has anybody implemented MS SQL Server support in tiOPF? If so, do you mind sharing? Though it normally takes 30-60 minutes to add a new persistence layer, but that is 30-60 I could save. ;-)

Regards,
- Graeme -

To my knowledge, there are pre-compiled freetds libraries available.

Could somebody explain the situation with SqlDB and MS SQL Server support? * Must I have C++ compiler

No, not if you have a pre-compiled binary version of the freetds library.

* Is the MS SQL Server support any good?

Relatively, although I would not say it is on par with e.g. Firebird, Postgres.

* What version of MS SQL Server is supported?

Any version that FreeTDS supports (up to 2008, if memory serves me well)

The program I am writing is going to run on the server which hosts SQL Server, so client libraries should all be there. Do I still need this FreeTDS library mentioned?

I think yes, I don't think that MS-SQL server still provides a native client library, it uses ADO as the 'native' layer.

Not to my knowledge.

Michael.

In our previous episode, Michael Van Canneyt said:

(afaik OLEDB, a layer deeper/older of which ADO is a superset, but conclusion is the same)

In our previous episode, Michael Van Canneyt said:

... from our site:

ftp://ftp.freepascal.org/fpc/contrib/windows/

client library,

> it uses ADO as the 'native' layer. (afaik OLEDB, a layer deeper/older of which ADO is a superset, but

conclusion is the same)

Using our Typelibrary converter and a bit of time we could write a ADO driver for SQL-DB, then the FreeTDS library wouldn't be needed to connect to a MS SQL server...

Regards,
Sven

In our previous episode, Sven Barth said:

Well, and SEH should be on by default for 32-bit I guess?

Anyway the typelibs seems to mostly work:

rem maybe following line needs fix on 32-bit

set inputdir=%CommonProgramFiles(x86)%
set outputdir=c:\tbls

echo from %inputdir% to %outputdir%

set flags=-a -d "%outputdir%" -p
mkdir %outputdir%
cd /d %inputdir%
for /r %%i in (*.tlb) do importtl %flags% "%%i"

I'm working with MSSQL perfectly using FPC 2.6.5 and Lazarus (trunk), only 32-bits.
You can use pre-compiled libs here ftp://ftp.freepascal.org/fpc/contrib/windows/

Regards,
Marcos Douglas

connect

> to a MS SQL server... Well, and SEH should be on by default for 32-bit I guess?

Definitely! :)

Anyway the typelibs seems to mostly work:

Do the generated units also compile?

Regards,
Sven

In our previous episode, Sven Barth said:

Yes, the only problem is that they are not OLEDB as Delphi has the unit. Probably more ADO like.

It seems that oledb itself has no typelib, at least I can't find it (scanned all files in common\ado and common\ole db), and others hint on it too ( http://www.gocher.me/ADO-Free-Pascal )

So manual conversion of the (huge) SDK header is the only way out it seems.

--------------------------
Final batch file:

del *.pas *.lpk *.ppu *.o

set inputdir="%CommonProgramFiles(x86)%\system\ado" set lazdir=d:\repo\lazarus
set outputdir=c:\tlbs

echo from %inputdir% to %outputdir%

set flags=-a -d "%outputdir%" -p
mkdir %outputdir%
cd /d %inputdir%
rem for /r %%i in (*.tlb) do importtl %flags% "%%i"

set inputdir="%CommonProgramFiles(x86)%\system\ole db"

cd /d %inputdir%
for /r %%i in (*.dll) do importtl %flags% "%%i"

cd %outputdir%

rem assumes lazarus compiled and activex component installed, flags on one line.

# rem on one line
set flags=-Fu%lazdir%\components\activex\lib\i386-win32 -Fu%lazdir%\lcl\units\i386-win32
-Fu%lazdir%\components\lazutils\lib\i386-win32

for /r %%i in (*_tlb.pas) do fpc %flags% "%%i"

Michael Van Canneyt wrote

To my knowledge, there are pre-compiled freetds libraries available.

Thanks, I got those from Marco's link he posted.

Relatively, although I would not say it is on par with e.g. Firebird, Postgres.

I'm only writing a small tool for monitoring a directory and importing CSV files. Not much data at a time, so I don't believe I'll stress SqlDB much.

> * What version of MS SQL Server is supported? Any version that FreeTDS supports (up to 2008, if memory serves me well)

Umm, I tested on MSSQL 2008 and it works fine, but the tool is ultimately going to run against MSSQL Express 2012. I'll have to do some more testing.

I think yes, I don't think that MS-SQL server still provides a native client library, it uses ADO as the 'native' layer.

That seems to be the case. I couldn't find the native client library anywhere. So in the end opted for the pre-compiled freetds libraries. So far so good.

> While I'm at it, has anybody implemented MS SQL Server support in tiOPF? Not to my knowledge.

No worries. In the end it took me a whopping 10 minutes to add a new MSSQL persistence layer. :-) I haven't run the unit tests yet, but basic CRUD functionality seems to work just fine.

My biggest issue today.... TDatetime handling. They caused INSERT statements to fail. In the end I found the problem. I use TIMESTAMP data type (like I'm used to under Firebird), but apparent for MSSQL that data type has nothing to do with date/time info. I was meant to use the DATETIME data type. After that, all worked well. :-)

Regards,
- Graeme -

Marco van de Voort wrote

... from our site: ftp://ftp.freepascal.org/fpc/contrib/windows/

Thanks again, that came in very useful.

Regards,
- Graeme -

Last night I googled some more. Conclusions:

1. the oledb.tlb isn't easy to find, but it does exist https://code.google.com/p/py-com-tools/source/browse/trunk/sdk-tlbs/?r=2

Maybe it is in the full platform SDK, but I didn't have that readily available.

The result doesn't compile, it's only a single issue though, it stuffs an interface in a variant record. (bug in importer, should probably be a pointer in that case)

2. sql server will phase oledb out. SQLserver 2012 is the last to support it (but MS will support it for existing versions for 7 years). oledb itself is not deprecated, only for sql server. (in practice that means it is still useful for access)

3. oledb is currently considered the high speed interface to sql server. ADO is categorized as moderate speed. ODBC is positioned as oledb's successor, but that is possibly only for future versions. For recent versions of sql server, odbc should be fast.

Problem is also that the generalized interfaces (ODBC/ADO) do not support all management functionality yet.