R2-Beta - DB 2.7.7 (odbc and other bugs)

Return to Index Page
Most recent messages (500 max) are listed first.

#UserMessageDate
137BrianHThe new FOREACH in R3 used with set-words should work better for your purposes, Paul. Offtopic here I suppose :(4-Apr-08 16:01
136TomCnot really , x y are copies of the values in the series and not the series itself that is in the foreach version instead of print x you could not have print [ first x first skip x -3]4-Apr-08 6:15
135RobertSforeach [x y] next series [print x ] has the desired effect b: next series forskip b 2 [print first b]4-Apr-08 1:45
134Paulmaybe we should fix some mezzanines a bit more. Don't like how forskip works much for example. Should be able to do forskip next series 2 without getting error.20-Mar-08 23:17
133CarlI don't think so.19-Mar-08 2:47
132GrahamIs there a limit to the number of connected LNS clients?18-Mar-08 23:50
131CarlYes.18-Mar-08 23:50
130Graham:)18-Mar-08 23:50
129GrahamOk, just to keep it in mind.18-Mar-08 23:49
128Carl(But, then, maybe not.)18-Mar-08 23:49
127CarlDepends on the version of R. In 3, should be easy. In 2, probably difficult.18-Mar-08 23:48
126Grahamsql server odbc is async or can be forced to either.18-Mar-08 23:48
125GrahamHow hard would it be to use a subprocess to get async on ODBC ?18-Mar-08 23:47
124GrahamI'm thinking of how well a LNS middle tier will perform.18-Mar-08 23:46
123CarlBut, it is good you noted it... and we need to be sure we keep track of such things somewhere.18-Mar-08 23:45
122CarlBecause, we could do what we do with other things like DNS, and use a subprocess to get async ability.18-Mar-08 23:44
121CarlWorst case would be that it could be async, but only one pending ODBC request at a time is allowed.18-Mar-08 23:44
120CarlI would think so, but not sure because it depends on implementation of ODBC.18-Mar-08 23:44
119GrahamWhat about ODBC?18-Mar-08 23:42
118CarlFor databases that support it.18-Mar-08 23:42
117GrahamCan database queries be made async?18-Mar-08 23:41
116CarlYes, it is a good question too.18-Mar-08 23:41
115GrahamI'm thinking of a complicated sql query .. that might take a few mins18-Mar-08 23:41
114CarlThe main pitfall would be requests that block as part of their service but not at the REBOL port wait llevel.18-Mar-08 23:40
113CarlTheading is not a guarantee of better throughput, it's main promise is fairness.18-Mar-08 23:37
112CarlIt is a balance -- and depends a great deal on what "a request that takes a long time" is.18-Mar-08 23:34
111GrahamWhat do the database experts say?18-Mar-08 20:26
110GrahamI'm guessing that one would need multiple LNS servers on different ports to take advantage of the multithreaded database server and to scale upwards.18-Mar-08 20:26
109GrahamThis is for the future. Most database engines are multithreaded. If one has a LNS server acting as a middle layer, and a client sends a request that takes a long time, this will block the other clients till it is completed. I presume that this will also act to prevent LNS scaling in this situation.18-Mar-08 20:20
108BrianHChanged tracker #45 to reflect the results of the above tests, and the decision to defer to after 2.7.6.14-Mar-08 18:32
107BrianHCool. That will help greatly.14-Mar-08 16:50
106Carlafter 2.7.6 is out, I can do a build that will print the quoted string so we can look at it14-Mar-08 16:39
105Carlmy guess is that the float value on the db side contains invalid chars14-Mar-08 16:39
104Carlreal and float are the same on this side14-Mar-08 16:38
103Carlconversion functions in clib are poor - we use our own.14-Mar-08 16:37
102BrianHI'm not mentioning this to make it a priority; I'm just posting the info while I still remember it.14-Mar-08 16:24
101BrianHSQL_FLOAT and SQL_REAL are converted the same way, just with different sizes. And yet SQL_REAL works and SQL_FLOAT doesn't, at least with SQL Native Client (an ODBC 3.5 driver). Perhaps that difference can point you in the right direction.14-Mar-08 15:56
100BrianHAre you allocating 8 bytes in the return value? I can't really tell you what API function I mean, as all of the API docs I found refer to ODBC 3+. In 3+ the call to convert a value from a SQL value to a C value ignores the buffer length parameter when converting SQL_FLOAT or SQL_REAL and just assumes the size of the C type (8 or 4 bytes, respectively).14-Mar-08 15:53
99CarlREBOL decimal type is 8-byte.14-Mar-08 3:35
98BrianHNote: The REAL type doesn't have this problem. REAL is a 4-byte float, while FLOAT without a length specifier is 8-byte. Perhaps it is an overflow problem or some other type of datatype conversion problem.14-Mar-08 1:16
97BrianHI haven't seen an ODBC 2 driver on a 32-bit operating system in years, but I'm more familiar with ODBC on Windows, not Unix.14-Mar-08 1:04
96BrianHIt's not really completely backwards compatible, but any ODBC 3.x driver manager will change the ODBC 2 application calls to its best approximation in ODBC 3 driver calls.14-Mar-08 1:03
95Grahamso that it's not really an either or situation.14-Mar-08 1:01
94GrahamAm I to understand that support odbc3 also infact supports odbc2 ?14-Mar-08 1:00
93BrianHBehavioral changes in ODBC after 2: http://msdn2.microsoft.com/en-us/library/ms714001(VS.85).aspx14-Mar-08 0:54
92CarlLet's hope no-one.14-Mar-08 0:51
91BrianHWhat drivers still use it?14-Mar-08 0:51
90BrianHI mean, intentionally :)14-Mar-08 0:51
89CarlYou do.14-Mar-08 0:50
88CarlSo, I have concluded that above BADMEM is correct - not an error. ODBC allows passing integers like this depending on the command.14-Mar-08 0:50
87BrianHWho still uses ODBC 2?14-Mar-08 0:48
86CarlWe can do it for 2.7.7.14-Mar-08 0:47
85CarlCorrect.14-Mar-08 0:47
84CarlThe change would invalidate all current ODBC usage as validation.14-Mar-08 0:47
83BrianHThis group is DB 2.7.7 :)14-Mar-08 0:47
82BrianHThe log is in my user directory.14-Mar-08 0:47
81CarlToo big a change this late in 2.7.6 release cycle.14-Mar-08 0:47
80BrianHPosted log from 2.7.5 test. Here's the test source:

db: open odbc://HJBDBConv dbc: first db insert dbc "select * from dbo.blah" print mold copy dbc close db

Here's the table source:

CREATE TABLE dbo.blah( a float NULL )

14-Mar-08 0:46
79GrahamAny reasons why it shouldn't be odbc3?14-Mar-08 0:46
78Graham1996 for ODBC is a long time ago.14-Mar-08 0:46
77CarlFrom docs: Note that if the Attribute argument is a driver-specific value, ValuePtr may be a signed integer.14-Mar-08 0:42
76Grahamfloat problem14-Mar-08 0:42
75GrahamPerhaps Brian should post his log .. I'm no longer sure my local install is okay since I don't get the decimal problem on a new install.14-Mar-08 0:42
74CarlMy gut tells me there is a bug lurking.14-Mar-08 0:41
73CarlSQL_ROWSET_SIZE Integer value that specifies the number of rows in the rowset, that is the number of rows that are returned by each call to SQLExtendedFetch. The default value is 1.14-Mar-08 0:40
72CarlIf that value is wrong, why does it return SQL_SUCCESS?14-Mar-08 0:38
71BrianHAn article about the differences between ODBC 2 and 3, from 1996: http://www.dbmsmag.com/9604d53.html14-Mar-08 0:38
70Grahamd: open odbc://remr p: first d insert p {select * from test} probe mold copy p insert p {select cast(t as decimal(9,3)) from test} probe mold copy p close d halt14-Mar-08 0:37
69CarlYou could have put that in a file. :/14-Mar-08 0:35
68Grahamoops .. the whole log14-Mar-08 0:35
67Grahamcmdview 454-a74 ENTER SQLAllocEnv HENV * 004DC3D8

cmdview 454-a74 EXIT SQLAllocEnv with return code 0 (SQL_SUCCESS) HENV * 0x004DC3D8 ( 0x00b51540)

cmdview 454-a74 ENTER SQLAllocConnect HENV 00B51540 HDBC * 0030FB70

cmdview 454-a74 EXIT SQLAllocConnect with return code 0 (SQL_SUCCESS) HENV 00B51540 HDBC * 0x0030FB70 ( 0x00b515e8)

cmdview 454-a74 ENTER SQLSetConnectOption HDBC 00B515E8 SQLINTEGER 111 <SQL_QUIET_MODE> SQLPOINTER 00000000

cmdview 454-a74 EXIT SQLSetConnectOption with return code 0 (SQL_SUCCESS) HDBC 00B515E8 SQLINTEGER 111 <SQL_QUIET_MODE> SQLPOINTER 00000000

cmdview 454-a74 ENTER SQLConnectW HDBC 00B515E8 WCHAR * 0x00B51718 [ 4] "remr" SWORD 4 WCHAR * 0x74329A38 [ -3] "******\ 0" SWORD -3 WCHAR * 0x74329A38 [ -3] "******\ 0" SWORD -3

cmdview 454-a74 EXIT SQLConnectW with return code 0 (SQL_SUCCESS) HDBC 00B515E8 WCHAR * 0x00B51718 [ 4] "remr" SWORD 4 WCHAR * 0x74329A38 [ -3] "******\ 0" SWORD -3 WCHAR * 0x74329A38 [ -3] "******\ 0" SWORD -3

cmdview 454-a74 ENTER SQLAllocStmt HDBC 00B515E8 HSTMT * 0030FB58

cmdview 454-a74 EXIT SQLAllocStmt with return code 0 (SQL_SUCCESS) HDBC 00B515E8 HSTMT * 0x0030FB58 ( 0x00b51ba8)

cmdview 454-a74 ENTER SQLSetStmtOption HSTMT 00B51BA8 UWORD 6 <SQL_CURSOR_TYPE> SQLPOINTER 0x00000002

cmdview 454-a74 EXIT SQLSetStmtOption with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 6 <SQL_CURSOR_TYPE> SQLPOINTER 0x00000002 (BADMEM)

cmdview 454-a74 ENTER SQLFreeStmt HSTMT 00B51BA8 UWORD 0 <SQL_CLOSE>

cmdview 454-a74 EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 0 <SQL_CLOSE>

cmdview 454-a74 ENTER SQLFreeStmt HSTMT 00B51BA8 UWORD 3 <SQL_RESET_PARAMS>

cmdview 454-a74 EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 3 <SQL_RESET_PARAMS>

cmdview 454-a74 ENTER SQLExecDirect HSTMT 00B51BA8 UCHAR * 0x01271D20 [ 18] "select * from test" SDWORD 18

cmdview 454-a74 EXIT SQLExecDirect with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UCHAR * 0x01271D20 [ 18] "select * from test" SDWORD 18

cmdview 454-a74 ENTER SQLNumResultCols HSTMT 00B51BA8 SWORD * 0x0030FC06

cmdview 454-a74 EXIT SQLNumResultCols with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 SWORD * 0x0030FC06 (1)

cmdview 454-a74 ENTER SQLDescribeCol HSTMT 00B51BA8 UWORD 1 UCHAR * 0x0030FB44 SWORD 127 SWORD * 0x0030FBC6 SWORD * 0x01270B70 SQLULEN * 0x01270B72 SWORD * 0x0030FBCE SWORD * 0x0030FBFA

cmdview 454-a74 EXIT SQLDescribeCol with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 1 UCHAR * 0x0030FB44 [ 1] "T" SWORD 127 SWORD * 0x0030FBC6 (1) SWORD * 0x01270B70 (7) SQLULEN * 0x01270B72 (24) SWORD * 0x0030FBCE (0) SWORD * 0x0030FBFA (1)

cmdview 454-a74 ENTER SQLSetStmtOption HSTMT 00B51BA8 UWORD 9 <SQL_ROWSET_SIZE> SQLPOINTER 0x0000000A

cmdview 454-a74 EXIT SQLSetStmtOption with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 9 <SQL_ROWSET_SIZE> SQLPOINTER 0x0000000A (BADMEM)

cmdview 454-a74 ENTER SQLSetStmtOption HSTMT 00B51BA8 UWORD 27 <unknown> SQLPOINTER [Unknown attribute 27]

cmdview 454-a74 EXIT SQLSetStmtOption with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 27 <unknown> SQLPOINTER [Unknown attribute 27]

cmdview 454-a74 ENTER SQLBindCol HSTMT 00B51BA8 UWORD 1 SWORD 1 <SQL_C_CHAR> PTR 0x01275520 SQLLEN 26 SQLLEN * 0x012684F8

cmdview 454-a74 EXIT SQLBindCol with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 1 SWORD 1 <SQL_C_CHAR> PTR 0x01275520 SQLLEN 26 SQLLEN * 0x012684F8 (19301632)

cmdview 454-a74 ENTER SQLExtendedFetch HSTMT 00B51BA8 UWORD 1 <SQL_FETCH_NEXT> SQLLEN 1 SQLULEN * 0x0030FB10 UWORD * 0x012684C8

cmdview 454-a74 EXIT SQLExtendedFetch with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 1 <SQL_FETCH_NEXT> SQLLEN 1 SQLULEN * 0x0030FB10 (1) UWORD * 0x012684C8 (0)

cmdview 454-a74 ENTER SQLFreeStmt HSTMT 00B51BA8 UWORD 2 <SQL_UNBIND>

cmdview 454-a74 EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 2 <SQL_UNBIND>

cmdview 454-a74 ENTER SQLFreeStmt HSTMT 00B51BA8 UWORD 0 <SQL_CLOSE>

cmdview 454-a74 EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 0 <SQL_CLOSE>

cmdview 454-a74 ENTER SQLFreeStmt HSTMT 00B51BA8 UWORD 3 <SQL_RESET_PARAMS>

cmdview 454-a74 EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 3 <SQL_RESET_PARAMS>

cmdview 454-a74 ENTER SQLExecDirect HSTMT 00B51BA8 UCHAR * 0x01268468 [ 40] "select cast(t as decimal(9,3)) from test" SDWORD 40

cmdview 454-a74 EXIT SQLExecDirect with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UCHAR * 0x01268468 [ 40] "select cast(t as decimal(9,3)) from test" SDWORD 40

cmdview 454-a74 ENTER SQLNumResultCols HSTMT 00B51BA8 SWORD * 0x0030FC06

cmdview 454-a74 EXIT SQLNumResultCols with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 SWORD * 0x0030FC06 (1)

cmdview 454-a74 ENTER SQLDescribeCol HSTMT 00B51BA8 UWORD 1 UCHAR * 0x0030FB44 SWORD 127 SWORD * 0x0030FBC6 SWORD * 0x01270B80 SQLULEN * 0x01270B82 SWORD * 0x0030FBCE SWORD * 0x0030FBFA

cmdview 454-a74 EXIT SQLDescribeCol with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 1 UCHAR * 0x0030FB44 [ 4] "CAST" SWORD 127 SWORD * 0x0030FBC6 (4) SWORD * 0x01270B80 (3) SQLULEN * 0x01270B82 (9) SWORD * 0x0030FBCE (3) SWORD * 0x0030FBFA (1)

cmdview 454-a74 ENTER SQLSetStmtOption HSTMT 00B51BA8 UWORD 9 <SQL_ROWSET_SIZE> SQLPOINTER 0x0000000A

cmdview 454-a74 EXIT SQLSetStmtOption with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 9 <SQL_ROWSET_SIZE> SQLPOINTER 0x0000000A (BADMEM)

cmdview 454-a74 ENTER SQLSetStmtOption HSTMT 00B51BA8 UWORD 27 <unknown> SQLPOINTER [Unknown attribute 27]

cmdview 454-a74 EXIT SQLSetStmtOption with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 27 <unknown> SQLPOINTER [Unknown attribute 27]

cmdview 454-a74 ENTER SQLBindCol HSTMT 00B51BA8 UWORD 1 SWORD 1 <SQL_C_CHAR> PTR 0x0125F640 SQLLEN 11 SQLLEN * 0x01268588

cmdview 454-a74 EXIT SQLBindCol with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 1 SWORD 1 <SQL_C_CHAR> PTR 0x0125F640 SQLLEN 11 SQLLEN * 0x01268588 (19301632)

cmdview 454-a74 ENTER SQLExtendedFetch HSTMT 00B51BA8 UWORD 1 <SQL_FETCH_NEXT> SQLLEN 1 SQLULEN * 0x0030FB10 UWORD * 0x01268558

cmdview 454-a74 EXIT SQLExtendedFetch with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 1 <SQL_FETCH_NEXT> SQLLEN 1 SQLULEN * 0x0030FB10 (1) UWORD * 0x01268558 (0)

cmdview 454-a74 ENTER SQLFreeStmt HSTMT 00B51BA8 UWORD 2 <SQL_UNBIND>

cmdview 454-a74 EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 2 <SQL_UNBIND>

cmdview 454-a74 ENTER SQLTransact HENV 00000000 HDBC 00B515E8 UWORD 1 <SQL_ROLLBACK>

cmdview 454-a74 EXIT SQLTransact with return code 0 (SQL_SUCCESS) HENV 00000000 HDBC 00B515E8 UWORD 1 <SQL_ROLLBACK>

cmdview 454-a74 ENTER SQLFreeStmt HSTMT 00B51BA8 UWORD 1 <SQL_DROP>

cmdview 454-a74 EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 00B51BA8 UWORD 1 <SQL_DROP>

cmdview 454-a74 ENTER SQLDisconnect HDBC 00B515E8

cmdview 454-a74 EXIT SQLDisconnect with return code 0 (SQL_SUCCESS) HDBC 00B515E8

cmdview 454-a74 ENTER SQLFreeConnect HDBC 00B515E8

cmdview 454-a74 EXIT SQLFreeConnect with return code 0 (SQL_SUCCESS) HDBC 00B515E8

cmdview 454-a74 ENTER SQLFreeEnv HENV 00B51540

cmdview 454-a74 EXIT SQLFreeEnv with return code 0 (SQL_SUCCESS) HENV 00B51540

14-Mar-08 0:35
66CarlThe invalid SetStmtOption.14-Mar-08 0:33
65CarlG: I am most concerned about that first error. Can you repost here.14-Mar-08 0:32
64Graham3.5114-Mar-08 0:31
63BrianHUnicode requires ODBC 3.5.14-Mar-08 0:31
62GrahamDoes unicode support require odbc3 ?14-Mar-08 0:30
61Gabrielethe one used by Qtask was done by Will Hare, so that's surely different.13-Mar-08 18:36
60OldesI tried it now, but it crashes with my Mysql513-Mar-08 16:38
59DocKimbelIIRC, Marteen did a light wrapper over libmysql and put it in rebol.org13-Mar-08 16:33
58GabrieleDoc: they are interfacing with libmysql, i'm not sure if their protocol is on rebol.rog (Edgar? did Will publish this?)13-Mar-08 15:02
57Gabrielepetr: the problem is the parsing of the result set when it is big, or at least so they say :)13-Mar-08 15:01
56DocKimbelGab: do you know how Qtask's C implementation performs compared to my mezz implementation or vs libmysql wrapper from rebol.org ? Do they rely on /Library to interface with REBOL ?13-Mar-08 14:53
55PekrAs for networking itself - I hope such discussion will happen. We need to get networking right this time ....13-Mar-08 12:38
54PekrGabriele - interesting - did it have any significant impact upon performance? I thought that time spent in driver is minimal, and that the most important part is complexity of query and performance of DB server.13-Mar-08 12:37
53GrahamBrian, will this work in sql server

>> insert p {select * from test} >> copy p == [[1.0] [none] [none]] >> insert p {select cast(t as decimal(9,3)) from test} >> copy p == [[1.0] [1.1] [2.1]]

13-Mar-08 10:22
52Gabrielebut, nothing stops anyone from doing a mezz implementation over TCP. R3 ports are async only, there is no sync mode. but you can do as I did for http. (although, there are things to discuss with Carl about that.)13-Mar-08 8:59
51GabrieleCarl's idea is to make a model as a C device (because not all DBs are accessible via TCP, and because performance matters with this stuff - Qtask moved to a C implementation of the MySQL protocol for eg.), to prove that the architecture is able to support something like a DB.13-Mar-08 8:57
50PekrDoc: you can talk to Gabriele about R3 tcp model. He wrote http 1.1 protocol for R3, so far the only scheme ported. There is also some info in DocBase.13-Mar-08 7:35
49DocKimbelThe direct protocol-level DB drivers approach that I've used for MySQL and Postgres proved to be a good choice, offering compact implementation (20-30 Kb vs several Mb for C drivers), excellent performances and great portability across all platforms supported by REBOL.13-Mar-08 0:11
48DocKimbelYeah I could port my DB drivers to R3 (easily I guess), but I don't know exactly what Carl has in mind for his model/example implementation. Can R3 ports work in sync mode (vs async) ?13-Mar-08 0:02
47BrianHThe SQL Native Client is a free download and supports connections to previous MSSQL databases - backwards compatible.12-Mar-08 20:31
46BrianHYou wouldn't get correct data from nchar or nvarchar fields in a non-Unicode REBOL. Those (misnamed in the SQL standard) datatypes are Unicode types.12-Mar-08 20:28
45GrahamI recall not getting correct data back from these fields ... but don't have sql server now to test.12-Mar-08 20:25
44GrahamBrian, did you notice any problems with nchar ?12-Mar-08 20:24
43BrianHIn my experience with the old and new versions, I mean.12-Mar-08 20:14
42BrianHThe new datatypes are varchar(max), nvarchar(max), and varbinary(max), which replace a few crappy old datatypes that MS inherited from Sybase. That and some language improvements are enough of an advantage to make it worth upgrading.12-Mar-08 20:13
41Carllunch time12-Mar-08 20:13
40CarlBut, in computing, everyone is supposed to just go along. Sheep..12-Mar-08 20:13
39CarlIn almost any other business market other than computing, their customers would kill them.12-Mar-08 20:11
38CarlNo, they do it for one reason alone, to force the entire market to upgrade.12-Mar-08 20:11
37BrianHYeah, one of the datatypes that they had to improve in 2005 was XML.12-Mar-08 20:10
36CarlBut, perhaps, it is quite possible I misunderstand what you mean by new datatypes.12-Mar-08 20:10
35CarlThe master concept that these companies embrace is XML, a method that allows unlimited extensibility.... so I would think they have a good idea about what is required in such a design.12-Mar-08 20:09
34CarlWhat? Off-base? No, my criticism is not the least bit off based. The whole point of the compsci in the 1990's was to invent extensible software. Adding new datatypes to a modern system is not a valid excuse, except for amateur coders.12-Mar-08 20:08
33BrianHBy the way, the new datatypes are a significant improvement over their predecessors, and the primary reason for upgrading to 2005.12-Mar-08 20:05
32BrianHDo you have some diagnostics you would like me to run?12-Mar-08 20:03
31BrianHIt returns the none value - I don't know what string you would be referring to.12-Mar-08 20:02
30BrianHSQL Server 2005 adds support for new datatypes. SQL Native Client supports these new datatypes, and is all-around a better driver. I understand that a lack of compatibility is a common problem for MS, but the criticism is off-base here.12-Mar-08 20:01
29CarlOn that float bug, can you take a look at what string it's returning? It must be formed in some odd way. Does it contain spaces or quotes?12-Mar-08 20:00
28CarlReally, is that true? Nah. Really? Isn't it interesting how the largest software company in the world, worth billions, cannot keep their own DB software compatible. Bill must think, "a sucker is born every year!"12-Mar-08 19:56
27BrianHNote that SQL Native Client is the only way to connect to SQL Server 2005 - the old SQL Server driver won't work with 2005.12-Mar-08 19:53
26BrianH(only tested on Server 2003 so far)12-Mar-08 19:44
25BrianHWe need to test the odbc driver with MS SQL Native Client as well, and make sure that all its datatypes are supported. The current version of R2 has Graham's float bug with the SQL Native Client.12-Mar-08 19:43
24Grahamif Nenad can take care of mysql and postgresql, and sql server is odbc, then something else such as firebird :)12-Mar-08 19:42
23GrahamI'd suggest whichever has the most compatible license12-Mar-08 19:41
22GabrieleNenad can do that easily ;)12-Mar-08 19:41
21BrianHI would love to see MySQL and PostgreSQL drivers based on their TCP protocols, rather than their client libs. That would deal with licensing issues and reduce the dependency size.12-Mar-08 19:40
20BrianHIf you use MySQL as the model, there may be some non-SQL-compatible stuff that will sneak into any drivers based on the reference model. If you use SQLite then the reference model wouldn't be server-based. So maybe both, with ODBC thrown in for good measure.12-Mar-08 19:38
19CarlNot for R3, since everything related to ports has changed.12-Mar-08 19:37
18GrahamWell, there are already drivers for mysql and sqlite12-Mar-08 19:35
17CarlBut, I am open to suggestions on it.12-Mar-08 19:34
16CarlI was planning to use SQLite as the model... or MySQL.12-Mar-08 19:34
15CarlYes, in R3 the plan is to open and release all those interfaces. Most likely, I will pick a single DB to code up as the model/example to serve as a guideline for the rest. (And to verify the design.)12-Mar-08 19:33
14GrahamSo, getting a native driver helps us getting our applications onto linux rather than having to use hacks like Wine.12-Mar-08 19:17
13GrahamFirebird is a nice small zero administration database .. so quite good for embedded applications. And it is used a lot in medical databases.12-Mar-08 19:16
12GrahamAnyway, with the new open source direction in R3 .. would it be possible to release what was done?12-Mar-08 19:14
11GrahamI seem to remember talking to someone about it ... some years ago12-Mar-08 19:14
10GrahamWas it Jeff who was doing all this work?12-Mar-08 19:13
9CarlWell, we pulled back on which db's to support directly, vs ODBC.12-Mar-08 19:13
8GrahamDid it work? Since it was never released ... it must have been tricky to determine demand!12-Mar-08 19:11
7CarlThere wasn't enough demand for it.12-Mar-08 19:07
6GrahamCarl, do you remember why RT abandoned the Interbase driver, and whether any of that driver will be usable for R3 or R2 ?12-Mar-08 18:14
5GrahamI did a new install and the problem has gone. Must be an old odbc driver or something. Brian .. do you still have the bug?12-Mar-08 7:55
4CarlDetails on my test are: used current Firebird ODBC (beta) and engine with Graham's test script. Worked w/o problem. Ran it from /Command.12-Mar-08 1:07
3GrahamBrian, I don't see a problem with decimal either, just float.11-Mar-08 22:53
2GrahamSee tracker #45 - not confirmed by Carl though, but confirmed by BrianH on sql-server 200511-Mar-08 22:53
1GrahamProblem with selecting float values from odbc.11-Mar-08 22:52

Return to Index Page