[freetds] SQLDescribeParam ?

[Björn Lundin]

Hi!
I have a Raspberry Pi (arm platform) running debian 6
which has unixodbc .

I installed this :

sudo apt-get install unixodbc unixodbc-dev odbcinst freetds
freetds-dev freetds-bin

and when I run a program towards a sql-server I get

Message: [Proc=SQLDescribeParam][Server=][State=IM001][unixODBC][Driver
Manager]Driver does not support this function

Ok, too bad, but I can live without that function.

However, when I run the same code on a windows client, it goes well,
using MS native client.


Anyway, my real problem is that when I have a DateTime2(3) column,
SQLDescribeParam returns
* SQL_VARCHAR

with MS native windows driver I get one of (not sure which, I treat
them equally)
* SQL_TYPE_TIMESTAMP
* SQL_DATETIME

Is there a way around this, to tell the client library to return a
correct datatype?

I'm not quite sure what lib or layer I'm supposed to look at.
odbc or tds.

isql does this:
(its column IXXLUTS that is behaving strange)
+---------------------------------------+
| Connected! |
| |
| sql-statement |
| help [tablename] |
| quit |
| |
+---------------------------------------+
SQL> help bseq
+------------------+--------------+------------+--------------+----------+-------------+------------
| TABLE_QUALIFIER | TABLE_OWNER | TABLE_NAME | COLUMN_NAME |
DATA_TYPE| TYPE_NAME | PRECISION
+------------------+--------------+------------+--------------+----------+-------------+------------
| sattmate | dbo | BSEQ | BSQPSTO | 12
| varchar | 2
| sattmate | dbo | BSEQ | BSQDSTO | 12
| varchar | 2
| sattmate | dbo | BSEQ | BSQTRTYP | 4
| int | 10
| sattmate | dbo | BSEQ | BSQID | 12
| varchar | 4
| sattmate | dbo | BSEQ | BSQPRIOR | 4
| int | 10
| sattmate | dbo | BSEQ | BSQBEGPR | 12
| varchar | 15
| sattmate | dbo | BSEQ | IXXLUPD | 12
| varchar | 12
| sattmate | dbo | BSEQ | IXXLUTS | -9
| datetime2 | 23
+------------------+--------------+------------+--------------+----------+-------------+------------


+------------+-------+-------+---------+---------+------------+--------------+-----------------
| LENGTH | SCALE | RADIX | NULLABLE| REMARKS | COLUMN_DEF |
SQL_DATA_TYPE| SQL_DATETIME_SUB
+------------+-------+-------+---------+---------+------------+--------------+-----------------
| 2 | | | 0 | | (' ') | 12
|
| 2 | | | 0 | | (' ') | 12
|
| 4 | 0 | 10 | 0 | | ((1)) | 4
|
| 4 | | | 0 | | (' ') | 12
|
| 4 | 0 | 10 | 1 | | ((1)) | 4
|
| 15 | | | 0 | | (' ') | 12
|
| 12 | | | 0 | | (' ') | 12
|
| 46 | | | 0 | | | -9
|
+------------+-------+-------+---------+---------+------------+--------------+-----------------


+------------------+-----------------+-------------+-------------+
| CHAR_OCTET_LENGTH| ORDINAL_POSITION| IS_NULLABLE | SS_DATA_TYPE|
+------------------+-----------------+-------------+-------------+
| 2 | 1 | NO | 39 |
| 2 | 2 | NO | 39 |
| | 3 | NO | 56 |
| 4 | 4 | NO | 39 |
| | 5 | YES | 38 |
| 15 | 6 | NO | 39 |
| 12 | 7 | NO | 39 |
| | 8 | NO | 0 |
+------------------+-----------------+-------------+-------------+

SQLRowCount returns 8

[James K. Lowden]

On Sun, 30 Sep 2012 20:57:43 +0200

Post by Björn Lundin
Anyway, my real problem is that when I have a DateTime2(3) column,
SQLDescribeParam returns
* SQL_VARCHAR
with MS native windows driver I get one of (not sure which, I treat
them equally)
* SQL_TYPE_TIMESTAMP
* SQL_DATETIME
Is there a way around this, to tell the client library to return a
correct datatype?

The library reports what it received from the server. The server
converted the SQL DATETIME2(3) datatype of the column to varchar
for compatibility with the TDS version you're using.

If you check with TDSDUMP, I believe you'll find you're connecting with
TDS 7.2. The first version of the protocol to support DATETIME2 is
TDS 7.3. The current release, 0.91, doesn't support TDS 7.3; to get
that, you'll need to use a recent snapshot.

(The snapshots are once again broken. I haven't had a chance to figure
out why. To get the absolute latest, you need git.)

Hoppas det blir klart.

--jkl

[Björn Lundin]

Post by James K. Lowden
If you check with TDSDUMP, I believe you'll find you're connecting with
TDS 7.2.

Correct, I do.

Post by James K. Lowden
The first version of the protocol to support DATETIME2 is
TDS 7.3. The current release, 0.91, doesn't support TDS 7.3;

Ok, that explains it

Post by James K. Lowden
to get that, you'll need to use a recent snapshot.
(The snapshots are once again broken. I haven't had a chance to figure
out why. To get the absolute latest, you need git.)

hmm, being a svn user, I've never touched git.
But I guess I'll need some sort of address?

Post by James K. Lowden
Hoppas det blir klart.

Crystal clear :-)

[James K. Lowden]

On Tue, 2 Oct 2012 10:57:13 +0200

Post by Björn Lundin

Post by James K. Lowden
to get that, you'll need to use a recent snapshot.
(The snapshots are once again broken. I haven't had a chance to
figure out why. To get the absolute latest, you need git.)

hmm, being a svn user, I've never touched git.
But I guess I'll need some sort of address?

I published the current snapshot at
ftp://ftp.freetds.org/pub/freetds/current/.

I attempted to fix the overnight snapshot process, too. Tomorrow we'll
see.

--jkl

[James K. Lowden]

On Tue, 2 Oct 2012 11:58:54 -0400

Post by James K. Lowden
I attempted to fix the overnight snapshot process, too. Tomorrow
we'll see.

Hmm. I must not be using git correctly. Could someone please
recommend a better approach? From last night's log:

output for Wed Oct 3 04:15:00 EDT 2012

cd /var/releng/freetds/Branch-0_91 && git clean && git pull
Removing freetds-0.92.79.tar.bz2
Removing freetds-0.92.79.tar.bz2.md5
Removing freetds-0.92.79.tar.gz
Removing freetds-0.92.79.tar.gz.md5
Removing make.log
Removing win32/freetds.nsh
Removing win32/version.rc
gitorious.org[0: 2a02:c0:1014::1]: errno=No route to host
Already up-to-date.
cd /var/releng/freetds/Branch-0_91 && sed "/^AC_INIT(FreeTDS/ s/,.*\
$/, 0.92.79)/" configure.ac | diff -u configure.ac - | patch
...
[success]

but for master, not so good:

cd /var/releng/freetds/master && git clean && git pull
Removing Makefile
Removing doc/Makefile
Removing freetds-dev.0.92.377.tar.bz2
Removing freetds-dev.0.92.377.tar.bz2.md5
Removing freetds-dev.0.92.377.tar.gz
Removing freetds-dev.0.92.377.tar.gz.md5
Removing include/Makefile
Removing make.log
Removing samples/Makefile
Removing src/Makefile
Not removing src/apps/.deps/
...
Removing src/tds/unittests/Makefile
Removing vms/Makefile
Removing win32/Makefile
Removing win32/msvc6/Makefile
gitorious.org[0: 2a02:c0:1014::1]: errno=No route to host
error: Your local changes to 'configure.ac' would be overwritten by
merge. Aborting. Please, commit your changes or stash them before you
can merge. Updating 1358a48..f72aa29
*** Error code 1

Stop.
[failure]

What I want is the equivalent of "svn revert", to return all files in
the working directory to their state in the repository. I don't really
want "git stash" but I guess maybe "git stash clear" might work?

Alternatively, I could "rm configure.ac" and let "git pull" recover it
for me.

--jkl

[Björn Lundin]

I published the current snapshot at ...

I downloaded snd compiled. Went fine.
Forgot the db-laptop at work though. Testing
This coming weekend.
Thanks for code
--
Bj?rn Lundin

[Björn Lundin]

I published the current snapshot at ...

I tried it today and it works :-)
Thanks a lot.
Now, my next challenge is to enable MARS in the odbc driver.

[Frediano Ziglio]

Post by Björn Lundin

I published the current snapshot at ...

I tried it today and it works :-)
Thanks a lot.
Now, my next challenge is to enable MARS in the odbc driver.

It's my challenge too :)

Still experimental at
https://gitorious.org/~freddy77/freetds/mars-freetds. Currently I'm
not even sure if last commit compile!

Frediano

[Björn Lundin]

Post by Frediano Ziglio
It's my challenge too :)
Still experimental at
https://gitorious.org/~freddy77/freetds/mars-freetds. Currently I'm
not even sure if last commit compile!

Is that based on 7.3?
James gave me a snapshot of 0.92 with TDS_Version 7.3
which supports DateTime2, which I think I also need...

[Craig A. Berry]

Post by James K. Lowden
error: Your local changes to 'configure.ac' would be overwritten by
merge. Aborting. Please, commit your changes or stash them before you
can merge. Updating 1358a48..f72aa29
*** Error code 1
Stop.
[failure]
What I want is the equivalent of "svn revert", to return all files in
the working directory to their state in the repository. I don't really
want "git stash" but I guess maybe "git stash clear" might work?
Alternatively, I could "rm configure.ac" and let "git pull" recover it
for me.

git reset --hard origin/master

should do the trick assuming you want to throw away local changes to configure.ac and get into exactly the same state as the remote repository. git pull would not recover those changes unless the remote already has them (is that what happened here?).

If you have local changes you want to keep, the easiest thing is to commit them and then do:

git pull --rebase

which does a rebase instead of a merge under the hood so that your local commits ?are set aside while getting in synch with the remote and then reapplied.

If you have local changes that you really don't want to commit yet for some reason, then I think you will have to look into git stash.

[James K. Lowden]

On Wed, 03 Oct 2012 18:05:29 +0000 (GMT)

Post by Craig A. Berry
git reset --hard origin/master
should do the trick assuming you want to throw away local changes to
configure.ac and get into exactly the same state as the remote
repository.

Thank you kindly, captain. This is the nightly tarballer; the local
changes are a result of munging configure.ac the night before with the
current mumble git number revision thing. Absolutely fine to discard
and replace (and repatch) with the server's version.

--hard
Matches the working tree and index to that of the tree being
switched to. Any changes to tracked files in the working
tree since <commit> are lost.

I read that before posting. "the tree being switched to" didn't sound
like what I wanted. It's the same old tree, possibly updated a
little.

Regards,

--jkl

[Frediano Ziglio]

Post by James K. Lowden
On Wed, 03 Oct 2012 18:05:29 +0000 (GMT)

Post by Craig A. Berry
git reset --hard origin/master
should do the trick assuming you want to throw away local changes to
configure.ac and get into exactly the same state as the remote
repository.

Thank you kindly, captain. This is the nightly tarballer; the local
changes are a result of munging configure.ac the night before with the
current mumble git number revision thing. Absolutely fine to discard
and replace (and repatch) with the server's version.
--hard
Matches the working tree and index to that of the tree being
switched to. Any changes to tracked files in the working
tree since <commit> are lost.
I read that before posting. "the tree being switched to" didn't sound
like what I wanted. It's the same old tree, possibly updated a
little.
Regards,
--jkl

Well, just a "git reset --hard" will do the trick as this does not
change your branch but just discard any changes you made from HEAD.

Frediano

[Craig A. Berry]

Post by Frediano Ziglio

Post by James K. Lowden
On Wed, 03 Oct 2012 18:05:29 +0000 (GMT)

Post by Craig A. Berry
git reset --hard origin/master
should do the trick assuming you want to throw away local changes to
configure.ac and get into exactly the same state as the remote
repository.

Thank you kindly, captain. This is the nightly tarballer; the local
changes are a result of munging configure.ac the night before with the
current mumble git number revision thing. Absolutely fine to discard
and replace (and repatch) with the server's version.
--hard
Matches the working tree and index to that of the tree being
switched to. Any changes to tracked files in the working
tree since <commit> are lost.
I read that before posting. "the tree being switched to" didn't sound
like what I wanted. It's the same old tree, possibly updated a
little.
Regards,
--jkl

Well, just a "git reset --hard" will do the trick as this does not
change your branch but just discard any changes you made from HEAD.

Yes, that should be sufficient in this case. But specifying the remote branch is a habit I've picked up to make sure I throw away any local, unpushed commits as well as any uncommitted changes. In other words, it's not just going back to the local HEAD that I may have messed with in ways I no longer wish to pursue, but to the upstream HEAD that represents something I trust more than my local repository.

________________________________________
Craig A. Berry
mailto:craigberry at mac.com

"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser