| # | User | Message | Date |
| 137 | BrianH | The new FOREACH in R3 used with set-words should work better for your purposes, Paul. Offtopic here I suppose :( | 4-Apr-08 16:01 |
| 136 | TomC | not 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 |
| 135 | RobertS | foreach [x y] next series [print x ] has the desired effect b: next series forskip b 2 [print first b] | 4-Apr-08 1:45 |
| 134 | Paul | maybe 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 |
| 133 | Carl | I don't think so. | 19-Mar-08 2:47 |
| 132 | Graham | Is there a limit to the number of connected LNS clients? | 18-Mar-08 23:50 |
| 131 | Carl | Yes. | 18-Mar-08 23:50 |
| 130 | Graham | :) | 18-Mar-08 23:50 |
| 129 | Graham | Ok, just to keep it in mind. | 18-Mar-08 23:49 |
| 128 | Carl | (But, then, maybe not.) | 18-Mar-08 23:49 |
| 127 | Carl | Depends on the version of R. In 3, should be easy. In 2, probably difficult. | 18-Mar-08 23:48 |
| 126 | Graham | sql server odbc is async or can be forced to either. | 18-Mar-08 23:48 |
| 125 | Graham | How hard would it be to use a subprocess to get async on ODBC ? | 18-Mar-08 23:47 |
| 124 | Graham | I'm thinking of how well a LNS middle tier will perform. | 18-Mar-08 23:46 |
| 123 | Carl | But, it is good you noted it... and we need to be sure we keep track of such things somewhere. | 18-Mar-08 23:45 |
| 122 | Carl | Because, we could do what we do with other things like DNS, and use a subprocess to get async ability. | 18-Mar-08 23:44 |
| 121 | Carl | Worst case would be that it could be async, but only one pending ODBC request at a time is allowed. | 18-Mar-08 23:44 |
| 120 | Carl | I would think so, but not sure because it depends on implementation of ODBC. | 18-Mar-08 23:44 |
| 119 | Graham | What about ODBC? | 18-Mar-08 23:42 |
| 118 | Carl | For databases that support it. | 18-Mar-08 23:42 |
| 117 | Graham | Can database queries be made async? | 18-Mar-08 23:41 |
| 116 | Carl | Yes, it is a good question too. | 18-Mar-08 23:41 |
| 115 | Graham | I'm thinking of a complicated sql query .. that might take a few mins | 18-Mar-08 23:41 |
| 114 | Carl | The 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 |
| 113 | Carl | Theading is not a guarantee of better throughput, it's main promise is fairness. | 18-Mar-08 23:37 |
| 112 | Carl | It is a balance -- and depends a great deal on what "a request that takes a long time" is. | 18-Mar-08 23:34 |
| 111 | Graham | What do the database experts say? | 18-Mar-08 20:26 |
| 110 | Graham | I'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 |
| 109 | Graham | This 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 |
| 108 | BrianH | Changed 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 |
| 107 | BrianH | Cool. That will help greatly. | 14-Mar-08 16:50 |
| 106 | Carl | after 2.7.6 is out, I can do a build that will print the quoted string so we can look at it | 14-Mar-08 16:39 |
| 105 | Carl | my guess is that the float value on the db side contains invalid chars | 14-Mar-08 16:39 |
| 104 | Carl | real and float are the same on this side | 14-Mar-08 16:38 |
| 103 | Carl | conversion functions in clib are poor - we use our own. | 14-Mar-08 16:37 |
| 102 | BrianH | I'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 |
| 101 | BrianH | SQL_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 |
| 100 | BrianH | Are 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 |
| 99 | Carl | REBOL decimal type is 8-byte. | 14-Mar-08 3:35 |
| 98 | BrianH | Note: 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 |
| 97 | BrianH | I 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 |
| 96 | BrianH | It'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 |
| 95 | Graham | so that it's not really an either or situation. | 14-Mar-08 1:01 |
| 94 | Graham | Am I to understand that support odbc3 also infact supports odbc2 ? | 14-Mar-08 1:00 |
| 93 | BrianH | Behavioral changes in ODBC after 2: http://msdn2.microsoft.com/en-us/library/ms714001(VS.85).aspx | 14-Mar-08 0:54 |
| 92 | Carl | Let's hope no-one. | 14-Mar-08 0:51 |
| 91 | BrianH | What drivers still use it? | 14-Mar-08 0:51 |
| 90 | BrianH | I mean, intentionally :) | 14-Mar-08 0:51 |
| 89 | Carl | You do. | 14-Mar-08 0:50 |
| 88 | Carl | So, 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 |
| 87 | BrianH | Who still uses ODBC 2? | 14-Mar-08 0:48 |
| 86 | Carl | We can do it for 2.7.7. | 14-Mar-08 0:47 |
| 85 | Carl | Correct. | 14-Mar-08 0:47 |
| 84 | Carl | The change would invalidate all current ODBC usage as validation. | 14-Mar-08 0:47 |
| 83 | BrianH | This group is DB 2.7.7 :) | 14-Mar-08 0:47 |
| 82 | BrianH | The log is in my user directory. | 14-Mar-08 0:47 |
| 81 | Carl | Too big a change this late in 2.7.6 release cycle. | 14-Mar-08 0:47 |
| 80 | BrianH | Posted 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 |
| 79 | Graham | Any reasons why it shouldn't be odbc3? | 14-Mar-08 0:46 |
| 78 | Graham | 1996 for ODBC is a long time ago. | 14-Mar-08 0:46 |
| 77 | Carl | From docs: Note that if the Attribute argument is a driver-specific value, ValuePtr may be a signed integer. | 14-Mar-08 0:42 |
| 76 | Graham | float problem | 14-Mar-08 0:42 |
| 75 | Graham | Perhaps 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 |
| 74 | Carl | My gut tells me there is a bug lurking. | 14-Mar-08 0:41 |
| 73 | Carl | SQL_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 |
| 72 | Carl | If that value is wrong, why does it return SQL_SUCCESS? | 14-Mar-08 0:38 |
| 71 | BrianH | An article about the differences between ODBC 2 and 3, from 1996: http://www.dbmsmag.com/9604d53.html | 14-Mar-08 0:38 |
| 70 | Graham | d: 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 halt | 14-Mar-08 0:37 |
| 69 | Carl | You could have put that in a file. :/ | 14-Mar-08 0:35 |
| 68 | Graham | oops .. the whole log | 14-Mar-08 0:35 |
| 67 | Graham | cmdview 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 |
| 66 | Carl | The invalid SetStmtOption. | 14-Mar-08 0:33 |
| 65 | Carl | G: I am most concerned about that first error. Can you repost here. | 14-Mar-08 0:32 |
| 64 | Graham | 3.51 | 14-Mar-08 0:31 |
| 63 | BrianH | Unicode requires ODBC 3.5. | 14-Mar-08 0:31 |
| 62 | Graham | Does unicode support require odbc3 ? | 14-Mar-08 0:30 |
| 61 | Gabriele | the one used by Qtask was done by Will Hare, so that's surely different. | 13-Mar-08 18:36 |
| 60 | Oldes | I tried it now, but it crashes with my Mysql5 | 13-Mar-08 16:38 |
| 59 | DocKimbel | IIRC, Marteen did a light wrapper over libmysql and put it in rebol.org | 13-Mar-08 16:33 |
| 58 | Gabriele | Doc: 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 |
| 57 | Gabriele | petr: the problem is the parsing of the result set when it is big, or at least so they say :) | 13-Mar-08 15:01 |
| 56 | DocKimbel | Gab: 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 |
| 55 | Pekr | As for networking itself - I hope such discussion will happen. We need to get networking right this time .... | 13-Mar-08 12:38 |
| 54 | Pekr | Gabriele - 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 |
| 53 | Graham | Brian, 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 |
| 52 | Gabriele | but, 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 |
| 51 | Gabriele | Carl'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 |
| 50 | Pekr | Doc: 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 |
| 49 | DocKimbel | The 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 |
| 48 | DocKimbel | Yeah 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 |
| 47 | BrianH | The SQL Native Client is a free download and supports connections to previous MSSQL databases - backwards compatible. | 12-Mar-08 20:31 |
| 46 | BrianH | You 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 |
| 45 | Graham | I recall not getting correct data back from these fields ... but don't have sql server now to test. | 12-Mar-08 20:25 |
| 44 | Graham | Brian, did you notice any problems with nchar ? | 12-Mar-08 20:24 |
| 43 | BrianH | In my experience with the old and new versions, I mean. | 12-Mar-08 20:14 |
| 42 | BrianH | The 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 |
| 41 | Carl | lunch time | 12-Mar-08 20:13 |
| 40 | Carl | But, in computing, everyone is supposed to just go along. Sheep.. | 12-Mar-08 20:13 |
| 39 | Carl | In almost any other business market other than computing, their customers would kill them. | 12-Mar-08 20:11 |
| 38 | Carl | No, they do it for one reason alone, to force the entire market to upgrade. | 12-Mar-08 20:11 |
| 37 | BrianH | Yeah, one of the datatypes that they had to improve in 2005 was XML. | 12-Mar-08 20:10 |
| 36 | Carl | But, perhaps, it is quite possible I misunderstand what you mean by new datatypes. | 12-Mar-08 20:10 |
| 35 | Carl | The 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 |
| 34 | Carl | What? 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 |
| 33 | BrianH | By 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 |
| 32 | BrianH | Do you have some diagnostics you would like me to run? | 12-Mar-08 20:03 |
| 31 | BrianH | It returns the none value - I don't know what string you would be referring to. | 12-Mar-08 20:02 |
| 30 | BrianH | SQL 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 |
| 29 | Carl | On 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 |
| 28 | Carl | Really, 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 |
| 27 | BrianH | Note 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 |
| 26 | BrianH | (only tested on Server 2003 so far) | 12-Mar-08 19:44 |
| 25 | BrianH | We 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 |
| 24 | Graham | if Nenad can take care of mysql and postgresql, and sql server is odbc, then something else such as firebird :) | 12-Mar-08 19:42 |
| 23 | Graham | I'd suggest whichever has the most compatible license | 12-Mar-08 19:41 |
| 22 | Gabriele | Nenad can do that easily ;) | 12-Mar-08 19:41 |
| 21 | BrianH | I 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 |
| 20 | BrianH | If 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 |
| 19 | Carl | Not for R3, since everything related to ports has changed. | 12-Mar-08 19:37 |
| 18 | Graham | Well, there are already drivers for mysql and sqlite | 12-Mar-08 19:35 |
| 17 | Carl | But, I am open to suggestions on it. | 12-Mar-08 19:34 |
| 16 | Carl | I was planning to use SQLite as the model... or MySQL. | 12-Mar-08 19:34 |
| 15 | Carl | Yes, 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 |
| 14 | Graham | So, getting a native driver helps us getting our applications onto linux rather than having to use hacks like Wine. | 12-Mar-08 19:17 |
| 13 | Graham | Firebird 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 |
| 12 | Graham | Anyway, with the new open source direction in R3 .. would it be possible to release what was done? | 12-Mar-08 19:14 |
| 11 | Graham | I seem to remember talking to someone about it ... some years ago | 12-Mar-08 19:14 |
| 10 | Graham | Was it Jeff who was doing all this work? | 12-Mar-08 19:13 |
| 9 | Carl | Well, we pulled back on which db's to support directly, vs ODBC. | 12-Mar-08 19:13 |
| 8 | Graham | Did it work? Since it was never released ... it must have been tricky to determine demand! | 12-Mar-08 19:11 |
| 7 | Carl | There wasn't enough demand for it. | 12-Mar-08 19:07 |
| 6 | Graham | Carl, 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 |
| 5 | Graham | I 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 |
| 4 | Carl | Details 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 |
| 3 | Graham | Brian, I don't see a problem with decimal either, just float. | 11-Mar-08 22:53 |
| 2 | Graham | See tracker #45 - not confirmed by Carl though, but confirmed by BrianH on sql-server 2005 | 11-Mar-08 22:53 |
| 1 | Graham | Problem with selecting float values from odbc. | 11-Mar-08 22:52 |