World: r4wp

Like the nchar and nvarchar types. OpenDBX converts those types to 
ASCII, then R3 would need to convert them back to Unicode.

A lot of the OpenDBX references to SQL Server don't seem to take 
SQL Server 2008 into account, so it's at least 3 versions behind 
now. Comparable to R2 I guess.

It makes a lot more sense to have OpenDBX bindings for R2 though, 
since the lack of Unicode support won't matter there.

OpenDBX is not a full SQL interface to databases, but a database 
abstraction of its own. They're probably not interested in supporting 
other features

There's another interesting product here - http://sqlrelay.sourceforge.net/

If you knew C, then you could add the nchar, and nvchar support

Knowing C, it would be better to add it to the ODBC API, at least 
for someone who already knows SQL. That way you can get wider database 
support, since most SQL database vendors support ODBC. Heck, even 
Microsoft is making a free unixodbc driver for MSSQL.

It isn't even clear how sqlrelay works

it sets up a tcp listener but I can't find the documentation of their 
line protocol

and windows support is not ready yet

No Rebol suppport of course.

So, Brian, want to ping Carl and ask for the ODBC sources for R2?

Is Carl "pingable" though? :-)

Not by me. And I use R3, almost never R2.

Carl maybe firewalled

Wait, how would you update the R2 protocol?

make the changes, send back to Carl, he releases new version

Wasn't Robert going to create a database driver for R3?

Ah. Well, I'd prefer to make the changes to the R3 version first, 
since we can use that right away. The internal code could be backported 
to the R2 version when Carl resurfaces.

ChristianE's odbc driver for R3 is already a little more useful than 
the R2 one, but needs a bit of work. Being open source, we can do 
the work.

Except so few of us use R3

But if we can leverage the work for red ....

Doc has (iirc) expressed an interest in adapting R3's port model 
to Red.

adapting or adopting?

Adopting. So much better than R2's port model.

So, we can reuse R3 documentation :)

Ha! R3's documentation for its port model is a bit lacking :(

There may need to be some tweaks for Red's ports due to the different 
language model though. Don't know for sure yet.

What's missing in the R3 port documentation is best practices examples 
for different usage models. The port model is so flexible you can 
almost use it as a way to create user-defined data types, but we're 
missing complex examples of the most efficient way to use the model. 
That's another reason I wanted to make a real R3-like odbc:// scheme, 
to learn the model better.

Oh, found that announcement about the end of OLEDB: http://blogs.msdn.com/b/sqlnativeclient/archive/2011/08/29/microsoft-is-aligning-with-odbc-for-native-relational-data-access.aspx

so reality forced MS to drop back to ODBC

Yup. You should see what they have in store for SQL Server 2012. 
It can be run on a fully command line OS, managed remotely entirely 
through PowerShell scripting. And you can do PowerShell scripting 
of MS servers from Linux clients too, reportedly.

PowerShell is a powerful scripting lanugage, but it is a mess, I 
don't understand why they never think about simplicity.

and put support engineers out of work??

Endo, that's an interesting topic; let's switch to Languages for 
that.

using rebol's ODBC interface, is there a way to get the names of 
the columns in the last select query?  sometimes, we do not provide 
the columns (select * from table) , so relying on assumptions to 
match return values and their columns is quite dangerous.

another example is retrieving the db metadata.  it would be nice 
to be able to know what columns do what from the returned data directly 
instead of assuming their order (which can change from one db version 
and provider to another)

With ChristianE's R3 ODBC, the initial insert dbport returns a header 
list translated to REBOL naming conventions, though it doesn't work 
right with unlabeled columns. Not sure with R2.

If you want to get the column metadata about a table, use the 'columns 
command:
- For R2: http://www.rebol.com/docs/database.html#section-27

- For R3: http://www.diefettenjahresindvorbei.de/odbc/odbc-docs.html#section-3.8
 though there's an error in the docs, so use 'columns instead of 
'tables

ok, so what do the columns returned by the [columns]  query mean? 
 (without docs, remember I'm not assuming the docs are up to date 
or even apply to Firebirds interface)


I tried to list the RDB$FIELDS metadata table, but it clearly doesn't 
match the columns output.

The docs for what the 'columns command returns are at the link for 
the R2 docs above.

except that SQL actualy does return the column headers, its a pity 
R2's ODBC interface doesn't seem to keep/read it.

The ODBC docs are up to date. Remember, the main problem with R2's 
ODBC support is that it hasn't changed at all in 11-12 years, though 
ODBC itself has. That does mean that the docs there are up to date.

ChristianE's R3 interface returns the column headers, though that 
does need some work.

I used 'columns and 'tables with R2 on SQL Server, it does work well.

Back in 2001 I created an intranet site for a local celebrity by 
making the database tables, then having R2 use the 'columns command 
to generate column lists that were used to autogenerate the server-side 
pages for the intranet. All it took was one function call per table 
to generate the whole site. Restyling the site just meant editing 
the HTML template in the function (this was before CSS was practical).

I may find some time to tweak the R3 ODBC-API a bit if you could 
supply a prioritized list of things that need work. Regarding problems 
with certain SQL types one easy workaround could be to just allow 
all types without direct support by rebol to read them as strings, 
you then could do anything you like withthem. Regarding "R3's documentation 
for its port model is a bit lacking" - I surely won't have any time 
to find out why the port model I used feels alien to R3 without the 
better R3 beeing documented anywhere.

We weren't requesting an update of the port model to you, Christian. 
That can wait until we have a better idea of what it should be.

Here is the code I use to load your ODBC extension, which patches 
it after load:

; Load and patch the ODBC extension
odbc: import/no-user %odbc.dll
unless 'case = pick body-of :system/schemes/odbc/actor/open 10 [

system/schemes/odbc/actor/open: func [port [port!] /local result] 
bind [
	port/state: context [access: 'write commit: 'auto] 

 result: open-connection port/locals: make database-prototype [] case 
 [
		string? select port/spec 'host [ajoin ["dsn=" port/spec/host]]
		string? select port/spec 'target [port/spec/target]
		'else [cause-error 'access 'invalid-spec port/spec]
	]

 all [block? result lit-word? first result apply :cause-error result] 
	port
] odbc
]

There was a bug in open with certain kinds of odbc port specs. The 
above code fixes that.