Connection to Red Brick

Hi all,

Is it possible to connect to an IBM Redbrick Database via Data Sources in AS 2005? I can't get to ODBC's and don't see an OLE driver.

Thanks in advance,

Mark

You must have a driver AND a cartridge that will work with Redbrick. The driver is pretty straightforward. The cartridge is an XSLT file that translates an internally generated XML-based query into a valid SQL statement for submission to the source system. On my system, the cartidges are available at:

C:\Program Files\Microsoft SQL Server\MSSQL.2\OLAP\bin\Cartridges

If a cartridge is not available for your specific system (which is the case for Redbrick), SSAS attempts to use the sql2000.xsl cartridge. This might work for you, but I'm not certain.

Another optoin for you is to create a set of views in SQL Server that use the OPENROWSET function to establish the connection to Redbrick for you. You might be able to then expose those views to SSAS and since SSAS has cartridges for SQL Server this might work out.

Good luck,

Bryan

|||

Thanks for the suggestions/guidance Bryan.

I appreciate the help.

Connection to ODBC without a DSN

Is it possible to connect to an ODBC driver (e.g. SQL Server or Oracle)
directly without having to create a DSN before hand.
This would be great as dumb users can't handle creating a DSN.
Would be nice if I could ask them SQL Server or Oracle, server name, user
name and password only and programmatically connect with that amount of
information.
Tony
You can use an OLEDB connection which is better anyway... see
http://www.aspfaq.com/2126 for samples that work in VB and ASP, and the
basic structure should work from any client language that supports it...
http://www.aspfaq.com/
(Reverse address to reply.)
"Tony" <tonyng2@.spacecommand.net> wrote in message
news:eRxayfHjEHA.1344@.TK2MSFTNGP11.phx.gbl...
> Is it possible to connect to an ODBC driver (e.g. SQL Server or Oracle)
> directly without having to create a DSN before hand.
> This would be great as dumb users can't handle creating a DSN.
> Would be nice if I could ask them SQL Server or Oracle, server name, user
> name and password only and programmatically connect with that amount of
> information.
> Tony
>
|||Nope, not an option, would require a total recode of my database layer.
I'm required to continue using ODBC.
Application is C++/MFC client server application.
Thanks,
Tony
P.S. I have heard that OLEDB runs slightly slower due to COM marshaling.
What makes it a better choice from a C++ perspective?
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:Of119iHjEHA.3608@.TK2MSFTNGP09.phx.gbl...[vbcol=seagreen]
> You can use an OLEDB connection which is better anyway... see
> http://www.aspfaq.com/2126 for samples that work in VB and ASP, and the
> basic structure should work from any client language that supports it...
> --
> http://www.aspfaq.com/
> (Reverse address to reply.)
>
>
> "Tony" <tonyng2@.spacecommand.net> wrote in message
> news:eRxayfHjEHA.1344@.TK2MSFTNGP11.phx.gbl...
user
>
|||You can use a dsn-less connection. Code the connection
string with the driver/provider you use in whatever syntax
is required for the data access api you are using with your
application.
OLE DB can provide more functionality and is generally
faster than ODBC.
-Sue
On Fri, 27 Aug 2004 16:17:36 -0500, "Tony"
<tonyng2@.spacecommand.net> wrote:

>Nope, not an option, would require a total recode of my database layer.
>I'm required to continue using ODBC.
>Application is C++/MFC client server application.
>Thanks,
>Tony
>P.S. I have heard that OLEDB runs slightly slower due to COM marshaling.
>What makes it a better choice from a C++ perspective?
>"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
>news:Of119iHjEHA.3608@.TK2MSFTNGP09.phx.gbl...
>user
>
|||To be more specific, you use SQLDriverConnect instead of SQLConnect.
You can even leverage the driver to prompt for the login information.
Here's an example:
SQLCHAR* connectionString = (SQLCHAR*)"driver={SQL
Server};database=mydatabase";
SQLDriverConnect(hdbc, hwnd, connectionString, SQL_NTS, NULL, 0, NULL,
SQL_DRIVER_PROMPT);
SQL_DRIVER_PROMPT will cause the driver to display a dialog prompting the
user for the server name and uid/pwd information.
As far as ODBC vs. OLEDB is concerned, OLEDB is nice, it is a lot more
flexible than ODBC, but it's also a lot more difficult to use. If you're
accessing simple, relational data, just use ODBC. If you're already using
ODBC, and you dont need some specific feature of OLEDB, just continue to use
ODBC.
Brannon
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:qp85j0pfp3pj7qgto5tt19arv0cp9ke86d@.4ax.com... [vbcol=seagreen]
> You can use a dsn-less connection. Code the connection
> string with the driver/provider you use in whatever syntax
> is required for the data access api you are using with your
> application.
> OLE DB can provide more functionality and is generally
> faster than ODBC.
> -Sue
> On Fri, 27 Aug 2004 16:17:36 -0500, "Tony"
> <tonyng2@.spacecommand.net> wrote:
it...[vbcol=seagreen]
Oracle)[vbcol=seagreen]
of
>
|||Thanks for the info.
I just need a way now to get the connection string used so I can save it for
next time.
Doesn't look like it gives it back to you.
Thanks,
Tony
"Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
news:uXeO4urjEHA.3624@.TK2MSFTNGP10.phx.gbl...
> To be more specific, you use SQLDriverConnect instead of SQLConnect.
> You can even leverage the driver to prompt for the login information.
> Here's an example:
> SQLCHAR* connectionString = (SQLCHAR*)"driver={SQL
> Server};database=mydatabase";
> SQLDriverConnect(hdbc, hwnd, connectionString, SQL_NTS, NULL, 0, NULL,
> SQL_DRIVER_PROMPT);
> SQL_DRIVER_PROMPT will cause the driver to display a dialog prompting the
> user for the server name and uid/pwd information.
> As far as ODBC vs. OLEDB is concerned, OLEDB is nice, it is a lot more
> flexible than ODBC, but it's also a lot more difficult to use. If you're
> accessing simple, relational data, just use ODBC. If you're already using
> ODBC, and you dont need some specific feature of OLEDB, just continue to
use[vbcol=seagreen]
> ODBC.
> Brannon
> "Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:qp85j0pfp3pj7qgto5tt19arv0cp9ke86d@.4ax.com...
marshaling.[vbcol=seagreen]
the[vbcol=seagreen]
> it...
> Oracle)
name,[vbcol=seagreen]
amount
> of
>
|||Why doesn't it look like it gives it back to you?
My example is a basic example of how to use SQLDriverConnect().
There are parameters on SQLDriverConnect() that return the connection string
that was used to connect.
Brannon
"Tony" <tonyng2@.spacecommand.net> wrote in message
news:OaQO8iujEHA.2544@.TK2MSFTNGP10.phx.gbl...
> Thanks for the info.
> I just need a way now to get the connection string used so I can save it
for[vbcol=seagreen]
> next time.
> Doesn't look like it gives it back to you.
> Thanks,
> Tony
>
> "Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
> news:uXeO4urjEHA.3624@.TK2MSFTNGP10.phx.gbl...
the[vbcol=seagreen]
you're[vbcol=seagreen]
using[vbcol=seagreen]
> use
layer.
> marshaling.
> the
> name,
> amount
>
|||I guess I have brain damage today, my apologies. :-)
Thanks for the reply,
Tony
"Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
news:eeMEES6jEHA.3876@.TK2MSFTNGP15.phx.gbl...
> Why doesn't it look like it gives it back to you?
> My example is a basic example of how to use SQLDriverConnect().
> There are parameters on SQLDriverConnect() that return the connection
string[vbcol=seagreen]
> that was used to connect.
> Brannon
> "Tony" <tonyng2@.spacecommand.net> wrote in message
> news:OaQO8iujEHA.2544@.TK2MSFTNGP10.phx.gbl...
> for
> the
> you're
> using
to[vbcol=seagreen]
> layer.
and[vbcol=seagreen]
supports
>

Connection to ODBC without a DSN

Is it possible to connect to an ODBC driver (e.g. SQL Server or Oracle)
directly without having to create a DSN before hand.
This would be great as dumb users can't handle creating a DSN.
Would be nice if I could ask them SQL Server or Oracle, server name, user
name and password only and programmatically connect with that amount of
information.
TonyYou can use an OLEDB connection which is better anyway... see
http://www.aspfaq.com/2126 for samples that work in VB and ASP, and the
basic structure should work from any client language that supports it...
http://www.aspfaq.com/
(Reverse address to reply.)
"Tony" <tonyng2@.spacecommand.net> wrote in message
news:eRxayfHjEHA.1344@.TK2MSFTNGP11.phx.gbl...
> Is it possible to connect to an ODBC driver (e.g. SQL Server or Oracle)
> directly without having to create a DSN before hand.
> This would be great as dumb users can't handle creating a DSN.
> Would be nice if I could ask them SQL Server or Oracle, server name, user
> name and password only and programmatically connect with that amount of
> information.
> Tony
>|||Nope, not an option, would require a total recode of my database layer.
I'm required to continue using ODBC.
Application is C++/MFC client server application.
Thanks,
Tony
P.S. I have heard that OLEDB runs slightly slower due to COM marshaling.
What makes it a better choice from a C++ perspective?
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:Of119iHjEHA.3608@.TK2MSFTNGP09.phx.gbl...
> You can use an OLEDB connection which is better anyway... see
> http://www.aspfaq.com/2126 for samples that work in VB and ASP, and the
> basic structure should work from any client language that supports it...
> --
> http://www.aspfaq.com/
> (Reverse address to reply.)
>
>
> "Tony" <tonyng2@.spacecommand.net> wrote in message
> news:eRxayfHjEHA.1344@.TK2MSFTNGP11.phx.gbl...
user[vbcol=seagreen]
>|||You can use a dsn-less connection. Code the connection
string with the driver/provider you use in whatever syntax
is required for the data access api you are using with your
application.
OLE DB can provide more functionality and is generally
faster than ODBC.
-Sue
On Fri, 27 Aug 2004 16:17:36 -0500, "Tony"
<tonyng2@.spacecommand.net> wrote:

>Nope, not an option, would require a total recode of my database layer.
>I'm required to continue using ODBC.
>Application is C++/MFC client server application.
>Thanks,
>Tony
>P.S. I have heard that OLEDB runs slightly slower due to COM marshaling.
>What makes it a better choice from a C++ perspective?
>"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
>news:Of119iHjEHA.3608@.TK2MSFTNGP09.phx.gbl...
>user
>|||To be more specific, you use SQLDriverConnect instead of SQLConnect.
You can even leverage the driver to prompt for the login information.
Here's an example:
SQLCHAR* connectionString = (SQLCHAR*)"driver={SQL
Server};database=mydatabase";
SQLDriverConnect(hdbc, hwnd, connectionString, SQL_NTS, NULL, 0, NULL,
SQL_DRIVER_PROMPT);
SQL_DRIVER_PROMPT will cause the driver to display a dialog prompting the
user for the server name and uid/pwd information.
As far as ODBC vs. OLEDB is concerned, OLEDB is nice, it is a lot more
flexible than ODBC, but it's also a lot more difficult to use. If you're
accessing simple, relational data, just use ODBC. If you're already using
ODBC, and you dont need some specific feature of OLEDB, just continue to use
ODBC.
Brannon
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:qp85j0pfp3pj7qgto5tt19arv0cp9ke86d@.
4ax.com...
> You can use a dsn-less connection. Code the connection
> string with the driver/provider you use in whatever syntax
> is required for the data access api you are using with your
> application.
> OLE DB can provide more functionality and is generally
> faster than ODBC.
> -Sue
> On Fri, 27 Aug 2004 16:17:36 -0500, "Tony"
> <tonyng2@.spacecommand.net> wrote:
>
it...[vbcol=seagreen]
Oracle)[vbcol=seagreen]
of[vbcol=seagreen]
>|||Thanks for the info.
I just need a way now to get the connection string used so I can save it for
next time.
Doesn't look like it gives it back to you.
Thanks,
Tony
"Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
news:uXeO4urjEHA.3624@.TK2MSFTNGP10.phx.gbl...
> To be more specific, you use SQLDriverConnect instead of SQLConnect.
> You can even leverage the driver to prompt for the login information.
> Here's an example:
> SQLCHAR* connectionString = (SQLCHAR*)"driver={SQL
> Server};database=mydatabase";
> SQLDriverConnect(hdbc, hwnd, connectionString, SQL_NTS, NULL, 0, NULL,
> SQL_DRIVER_PROMPT);
> SQL_DRIVER_PROMPT will cause the driver to display a dialog prompting the
> user for the server name and uid/pwd information.
> As far as ODBC vs. OLEDB is concerned, OLEDB is nice, it is a lot more
> flexible than ODBC, but it's also a lot more difficult to use. If you're
> accessing simple, relational data, just use ODBC. If you're already using
> ODBC, and you dont need some specific feature of OLEDB, just continue to
use
> ODBC.
> Brannon
> "Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:qp85j0pfp3pj7qgto5tt19arv0cp9ke86d@.
4ax.com...
marshaling.[vbcol=seagreen]
the[vbcol=seagreen]
> it...
> Oracle)
name,[vbcol=seagreen]
amount[vbcol=seagreen]
> of
>|||Why doesn't it look like it gives it back to you?
My example is a basic example of how to use SQLDriverConnect().
There are parameters on SQLDriverConnect() that return the connection string
that was used to connect.
Brannon
"Tony" <tonyng2@.spacecommand.net> wrote in message
news:OaQO8iujEHA.2544@.TK2MSFTNGP10.phx.gbl...
> Thanks for the info.
> I just need a way now to get the connection string used so I can save it
for
> next time.
> Doesn't look like it gives it back to you.
> Thanks,
> Tony
>
> "Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
> news:uXeO4urjEHA.3624@.TK2MSFTNGP10.phx.gbl...
the[vbcol=seagreen]
you're[vbcol=seagreen]
using[vbcol=seagreen]
> use
layer.[vbcol=seagreen]
> marshaling.
> the
> name,
> amount
>|||I guess I have brain damage today, my apologies. :-)
Thanks for the reply,
Tony
"Brannon Jones" <brannonjNOSPAM@.gmail.com> wrote in message
news:eeMEES6jEHA.3876@.TK2MSFTNGP15.phx.gbl...
> Why doesn't it look like it gives it back to you?
> My example is a basic example of how to use SQLDriverConnect().
> There are parameters on SQLDriverConnect() that return the connection
string
> that was used to connect.
> Brannon
> "Tony" <tonyng2@.spacecommand.net> wrote in message
> news:OaQO8iujEHA.2544@.TK2MSFTNGP10.phx.gbl...
> for
> the
> you're
> using
to[vbcol=seagreen]
> layer.
and[vbcol=seagreen]
supports[vbcol=seagreen]
>

Connection SQL Server 2005 with DNS hostname mismatch

When using the MS SQL 2005 JDBC driver, I now need to have the DNS name
resolution to the client correctly set up. If not I get the following
error:

SQLState: 08S01
SQLError: 0
Message: hostname : hostname

Where "hostname" is the client host name. It doesn't seem to matter if
I
use an IP address or hostname in my connection URL. When searching the
net,
I have seen a similar error, but not exactly the same, where the
message is
"Hostname: hostname not found" (once again, here "hostname" is the
client
machine) where they suggested the issue was the DNS name conflict.

I found the error goes away if the client machine's hostname match the
DNS
name used for the same IP addess that the DB server is using. One
work-around is to set hostname on the client to the IP address being
used.

I know the right thing to do is set the hostname and the DNS name
lookup the
same, but I have a customer who doesn't want to do this. They didn't
have to
for 2003, and they don't want to for 2005. Sigh. Is there a way to
disable
this feature?Hi Mark

It is not clear what exactly the problem is here. Is the problem that you
have renamed the server without changing the instance name? In which case
you need to drop the server and re-create it as described in
http://msdn.microsoft.com/library/d...nstall_5r8f.asp
John

"Mark Delaney" <drsparc@.gmail.comwrote in message
news:1167352406.739648.91440@.s34g2000cwa.googlegro ups.com...

Quote:

Originally Posted by

When using the MS SQL 2005 JDBC driver, I now need to have the DNS name
resolution to the client correctly set up. If not I get the following
error:
>
SQLState: 08S01
SQLError: 0
Message: hostname : hostname
>
Where "hostname" is the client host name. It doesn't seem to matter if
I
use an IP address or hostname in my connection URL. When searching the
net,
I have seen a similar error, but not exactly the same, where the
message is
"Hostname: hostname not found" (once again, here "hostname" is the
client
machine) where they suggested the issue was the DNS name conflict.
>
I found the error goes away if the client machine's hostname match the
DNS
name used for the same IP addess that the DB server is using. One
work-around is to set hostname on the client to the IP address being
used.
>
I know the right thing to do is set the hostname and the DNS name
lookup the
same, but I have a customer who doesn't want to do this. They didn't
have to
for 2003, and they don't want to for 2005. Sigh. Is there a way to
disable
this feature?
>

|||Hey,

It isn't the database server name that is in question. The hostname of
the machine where the client is running is the issue. If I try and
make a JDBC connection from a machine where the hostname doesn't match
what the DB server's DNS lists it as, then the connection is rejected.
This didn't happen with the 2003 JDBC driver, so it looks like a new
security feature. But I would like to disable it.

- Mark

John Bell wrote:

Quote:

Originally Posted by

Hi Mark
>
It is not clear what exactly the problem is here. Is the problem that you
have renamed the server without changing the instance name? In which case
you need to drop the server and re-create it as described in
http://msdn.microsoft.com/library/d...nstall_5r8f.asp
>
John
>
"Mark Delaney" <drsparc@.gmail.comwrote in message
news:1167352406.739648.91440@.s34g2000cwa.googlegro ups.com...

Quote:

Originally Posted by

When using the MS SQL 2005 JDBC driver, I now need to have the DNS name
resolution to the client correctly set up. If not I get the following
error:

SQLState: 08S01
SQLError: 0
Message: hostname : hostname

Where "hostname" is the client host name. It doesn't seem to matter if
I
use an IP address or hostname in my connection URL. When searching the
net,
I have seen a similar error, but not exactly the same, where the
message is
"Hostname: hostname not found" (once again, here "hostname" is the
client
machine) where they suggested the issue was the DNS name conflict.

I found the error goes away if the client machine's hostname match the
DNS
name used for the same IP addess that the DB server is using. One
work-around is to set hostname on the client to the IP address being
used.

I know the right thing to do is set the hostname and the DNS name
lookup the
same, but I have a customer who doesn't want to do this. They didn't
have to
for 2003, and they don't want to for 2005. Sigh. Is there a way to
disable
this feature?

|||Hi Mark

"Mark Delaney" <drsparc@.gmail.comwrote in message
news:1167431063.785847.116630@.48g2000cwx.googlegro ups.com...

Quote:

Originally Posted by

Hey,
>
It isn't the database server name that is in question. The hostname of
the machine where the client is running is the issue. If I try and
make a JDBC connection from a machine where the hostname doesn't match
what the DB server's DNS lists it as, then the connection is rejected.
This didn't happen with the 2003 JDBC driver, so it looks like a new
security feature. But I would like to disable it.
>
>
- Mark

I am not sure why this would cause a problem when connecting to the server,
there must be some conversation being carried out! I would expect it to
cause problems for other applications as well, therefore you may want to
resolve the issue for those. I assume you can't change the hosts file on the
server? Your post in microsoft.public.sqlserver.jdbcdriver has had no
replies yet!

John

Connection Reset

Hi all

I have build an application on top of SQL Server 2005 and i am using microsoft driver. My application stops periodically becoz of Database Connection Loss and I get the following exception

com.microsoft.sqlserver.jdbc.SQLServerException: An exception occurred during the DBComms.transmit operation. Exception:Socket closed. Context:(5) [Thread[Thread-55,5,main], IO:7e2dc, Dbc:null].
10:06:14:703 AM at com.microsoft.sqlserver.jdbc.SQLServerException.ma keFromDriverError(Unknown Source)
10:06:14:703 AM at com.microsoft.sqlserver.jdbc.DBComms.transmit(Unkn own Source)
10:06:14:703 AM at com.microsoft.sqlserver.jdbc.IOBuffer.sendCommand( Unknown Source)
10:06:14:703 AM at com.microsoft.sqlserver.jdbc.SQLServerStatement.se ndExecute(Unknown Source)
10:06:14:703 AM at com.microsoft.sqlserver.jdbc.SQLServerStatement.do ExecuteQuery(Unknown Source)
10:06:14:703 AM at com.microsoft.sqlserver.jdbc.SQLServerPreparedStat ement.executeQuery(Unknown Source)

Unable to find the exact reason for the above problem. Pl advice

Thanks & Rgds
RoshiniIt apppears to me that you get some kind of timeout, and the connection is closed, but I might be proven wrong. Nevertheless, you should handle such cases, as this may happen even in the most critical high availability solutions, for instance if a SQL Server Cluster is failing over. Applications should be able to reconnect automagically.

Connection problems

Am working on a SQL Server 2000 db with Powerbuilder 8 as the frontend. For
months our endusers connected thru the SQL Server native driver for version
6. Now, have just ported the application to Powerbuilder 10, and I
understand that the native drivers for SQL Server 2000 no longer exist in
Powerbuilder, and you are expected to use OLEDB or ODBC. Thinking that
OLEDB was the preferred method, I attempted to connect to the Server with
this Profile in Powerbuilder. I could connect fine, but it frooze everyone
else out. Anyone else have this problem, and if, how did you resolve it?
So, some more questions:
1). What is the preferred way to connect to SQL Server 2000, OLEDB or ODBC.
2). What is the fastest connection?William F. O'Neill (wfoneill@.bellsouth.net) writes:
> Am working on a SQL Server 2000 db with Powerbuilder 8 as the frontend.
> For months our endusers connected thru the SQL Server native driver for
> version 6. Now, have just ported the application to Powerbuilder 10,
> and I understand that the native drivers for SQL Server 2000 no longer
> exist in Powerbuilder, and you are expected to use OLEDB or ODBC.

I suppose that what you call "native drivers" is the old DB-Library
API, that I know that older versions of Powerbuilder used. MS has
deprecated this API, and have not made any development to it since
1998, so with DB-Lib you lack support for a lot of new stuff. All reason
to change.

> Thinking that OLEDB was the preferred method, I attempted to connect to
> the Server with this Profile in Powerbuilder. I could connect fine, but
> it frooze everyone else out. Anyone else have this problem, and if, how
> did you resolve it? So, some more questions:
> 1). What is the preferred way to connect to SQL Server 2000, OLEDB or
> ODBC.
> 2). What is the fastest connection?

It's not that OLE DB locks up the database by its own. There must be
something to it, but with zero knowledge of your environment, I have no
clue what it might be.

My prime choice would be SQLOLEDB to connect. But I need to add the
disclaimer that I have no experience of Powerbuilder, and it depends a
little on the API that Powerbuilder gives you. What you should not
use is OLE DB over ODBC, but make sure that you have Provider=SQLOLEDB
in your connectstring.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Connection Problem using the SQLClient Driver

I can create a Data Source in Visual Studio (BIDS) using the OLE DB Provider for Analysis Services 9.0 Provider without error. However, when I try to use the .NET SqlClient Provider, I cannot access any databases running under Analysis Services.

With the .NET Provider selected, I enter the server name. When I go to select a database name, only my SQL Server Databases populate the drop down list. If I manually enter the Analysis Server dB, I get a log in error.

Is there some configuration I need to set to allow the .NET Driver access to my Analysis Services databases?

Use ADOMD.NET .NET object model to access Analysis Services.

Edward.
--
This posting is provided "AS IS" with no warranties, and confers no rights