World: r4wp

ChristianE implements an R2-like API in an R3 port model, and it 
just feels alien, though it does allow me to have more portable code 
between R2 and R3. This helps when i have to have a script extract 
data in R2 because it needs to get text or numeric type data, but 
then close and call itself in R3 to parse that data. My %rebol.r 
is R2 and R3 compatible.

I figured out a way to make an R3-like ODBC API, and have an R2-like 
API emulated when you try to use it in an R2-like way. But then I 
ran out of time, was assigned to other projects for a while.

Nowadays I mostly write SQL, sometimes calling that SQL using R3, 
or others call it with ASP.NET, PHP or Java (merger code collection).

OpenDBX: Where are the REBOL drivers? The link on their site doesn't 
work.

http://www.compkarori.co.nz:8000/OpenDBX

Darn, OpenDBX's support for MSSQL is worse than REBOL's :(

OLEDB vs. ODBC; from Microsoft: "You are strongly encouraged to use 
one of the native OLE DB Providers

instead of the Microsoft Open Database Connectivity (ODBC) Provider. 
Native

OLE DB Providers provide better application stability and performance."

at least for it was for SQL Server. But as you said OLEDB is now 
obsolete..

Yup, that must be an old quote, from back when they were promoting 
OLE DB so your code would be non-portable. They don't do that anymore. 
Now their new ODBC stacks in Vista and 7 are better than OLE DB.

http://linuxnetworks.de/doc/index.php/OpenDBX/DBMS_Datatypes

what is exactly defiicient?  I never used sql server

BrianH: yes, this is an old quote. 
OpenDBX's support for MSSQL is worse than REBOL's

 - it doesn't look that bad, just new datatypes are not supported 
 like TIME, DATE.

Not new, core types. There are types OpenDBX can't that I am required 
to support.

can't -> can't handle

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)