Hello,
I was wondering if there is a tool available that maps the
relationships between tables in a SQL Server database.
I need this to help document a user guide to a DB I've designed for
them and they are familair with the MS Access diagrams and can't get
on with the diagrams Enterprise Manager produces.
However I want the tool to "attach" the relations to the Primary Key
and Foreign Keys regardless of where I drag the tables around, an
awful lot like MS Access relationship diagrams do. I've trawled
through many "trails" offered on the internet and thought I'd be
better off "asking the audience" for any recommendations.
Thanks for any help
Giles
If you want to document your database, you might check out SqlSpec, a
shareware app I wrote: http://www.elsasoft.org
Giles wrote:
>Hello,
>I was wondering if there is a tool available that maps the
>relationships between tables in a SQL Server database.
>I need this to help document a user guide to a DB I've designed for
>them and they are familair with the MS Access diagrams and can't get
>on with the diagrams Enterprise Manager produces.
>However I want the tool to "attach" the relations to the Primary Key
>and Foreign Keys regardless of where I drag the tables around, an
>awful lot like MS Access relationship diagrams do. I've trawled
>through many "trails" offered on the internet and thought I'd be
>better off "asking the audience" for any recommendations.
>Thanks for any help
>Giles
|||On 17 May, 21:29, "jezemine" <u34287@.uwe> wrote:
> If you want to document your database, you might check out SqlSpec, a
>
> shareware app I wrote:http://www.elsasoft.org
> Giles wrote:
>
>
> - Show quoted text -
Thanks for the tip, pretty looking app, but unfortunatley it still
doesn't map the relationships as I require.
Ta
Giles
sql
Showing posts with label tool. Show all posts
Showing posts with label tool. Show all posts
Wednesday, March 28, 2012
Saturday, February 25, 2012
registering SQL Server not in domain
Hi all,
We have standardized on Hyperion as our reporting tool. So far I have
only set up a couple of Access databases as data sources for it. Now
there is a request to report off our eOn (telephony management) SQL
Server database using Hyperion. The eOn SQL Server box is in a
workgroup that is not part of the rest of our domain. (We only have
one domain because we don't have a "forest", whatever that means.) It
is behind a router owned by eOn along with a PBX and some other stuff.
Setting up a data source for Hyperion requires creating a special data
source file called an .oce on the box where the Hyperion fat client
(required for most administrative tasks) resides, and also setting up a
different special data source file called a .das on the server where
the Hyperion services run. (The analysts and end-users do not have the
fat client, their access is web-based.)
I have to register the eOn SQL Server by using the IP address and SQL
Server authentication. (I was told that I can't use Windows
authentication because it is not in the domain.) From the box on
which the Hyperion fat client resides, I cannot register the eOn SQL
Server. The error message is "timeout expired". Tracerting indicates
there are no intermediate hops when attempting to connect from this
VLAN. From my desktop, which is on a different VLAN, I can connect to
and register it. This trip includes one hop at our 6509. From one of
my servers which is on the same VLAN as the fat-client box, I am able
to connect and register. On the fat-client box I tried deleting and
re-registering another SQL Server and there was no problem.
The IP address I have to use to connect to the eOn SQL Server is *NOT*
the actual IP address of the box it resides on, but rather the eOn
router, which translates it to the address of the server. We have no
control over this, eOn creates this setup. I'm not sure how it knows
which of the devices behind it a given message is for.
Ideas?Hi
Which version of SQL Server is on the telephony management system? At a
guess it is MSDE with no network protocols installed! Use svrnetcn.exe to
enable the network protcols. If they are running you may want to use the
SQLRecon tool to see what servers are available on your network
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=26
John
"Ellen K" wrote:
> Hi all,
> We have standardized on Hyperion as our reporting tool. So far I have
> only set up a couple of Access databases as data sources for it. Now
> there is a request to report off our eOn (telephony management) SQL
> Server database using Hyperion. The eOn SQL Server box is in a
> workgroup that is not part of the rest of our domain. (We only have
> one domain because we don't have a "forest", whatever that means.) It
> is behind a router owned by eOn along with a PBX and some other stuff.
>
> Setting up a data source for Hyperion requires creating a special data
> source file called an .oce on the box where the Hyperion fat client
> (required for most administrative tasks) resides, and also setting up a
> different special data source file called a .das on the server where
> the Hyperion services run. (The analysts and end-users do not have the
> fat client, their access is web-based.)
> I have to register the eOn SQL Server by using the IP address and SQL
> Server authentication. (I was told that I can't use Windows
> authentication because it is not in the domain.) From the box on
> which the Hyperion fat client resides, I cannot register the eOn SQL
> Server. The error message is "timeout expired". Tracerting indicates
> there are no intermediate hops when attempting to connect from this
> VLAN. From my desktop, which is on a different VLAN, I can connect to
> and register it. This trip includes one hop at our 6509. From one of
> my servers which is on the same VLAN as the fat-client box, I am able
> to connect and register. On the fat-client box I tried deleting and
> re-registering another SQL Server and there was no problem.
> The IP address I have to use to connect to the eOn SQL Server is *NOT*
> the actual IP address of the box it resides on, but rather the eOn
> router, which translates it to the address of the server. We have no
> control over this, eOn creates this setup. I'm not sure how it knows
> which of the devices behind it a given message is for.
> Ideas?
>|||Hi John,
Thanks for your response. I will check the version and also check
which network protocols are enabled on it, assuming I can get to the
box. But if the problem were no network protocols installed on the eOn
box then how would the other two boxes that CAN register it be able to
do so?
Thanks,
Ellen|||Hi
I hadn't realised that it could be registered elsewhere! This indicates that
there are network protocols, but they still may not be the same as the ones
on the client that can't register!! You may still want to try running
SQLRecon and also try to telnet into the port being used.
John
"Ellen K" wrote:
> Hi John,
> Thanks for your response. I will check the version and also check
> which network protocols are enabled on it, assuming I can get to the
> box. But if the problem were no network protocols installed on the eOn
> box then how would the other two boxes that CAN register it be able to
> do so?
> Thanks,
> Ellen
>|||Hi John,
Yes, I mentioned in my original post that I could register it from both
my desktop and from one of "my" servers.
The network protocols are the same on the eOn box as on "my" servers:
named pipes and tcp. Since the fat client can connect to "my" servers,
I think it's safe to say this isn't the problem.
I have now succeeded in creating an ODBC connection, which would not
have been my first choice, but right now if it works I'm happy.
Thanks,
Ellen
We have standardized on Hyperion as our reporting tool. So far I have
only set up a couple of Access databases as data sources for it. Now
there is a request to report off our eOn (telephony management) SQL
Server database using Hyperion. The eOn SQL Server box is in a
workgroup that is not part of the rest of our domain. (We only have
one domain because we don't have a "forest", whatever that means.) It
is behind a router owned by eOn along with a PBX and some other stuff.
Setting up a data source for Hyperion requires creating a special data
source file called an .oce on the box where the Hyperion fat client
(required for most administrative tasks) resides, and also setting up a
different special data source file called a .das on the server where
the Hyperion services run. (The analysts and end-users do not have the
fat client, their access is web-based.)
I have to register the eOn SQL Server by using the IP address and SQL
Server authentication. (I was told that I can't use Windows
authentication because it is not in the domain.) From the box on
which the Hyperion fat client resides, I cannot register the eOn SQL
Server. The error message is "timeout expired". Tracerting indicates
there are no intermediate hops when attempting to connect from this
VLAN. From my desktop, which is on a different VLAN, I can connect to
and register it. This trip includes one hop at our 6509. From one of
my servers which is on the same VLAN as the fat-client box, I am able
to connect and register. On the fat-client box I tried deleting and
re-registering another SQL Server and there was no problem.
The IP address I have to use to connect to the eOn SQL Server is *NOT*
the actual IP address of the box it resides on, but rather the eOn
router, which translates it to the address of the server. We have no
control over this, eOn creates this setup. I'm not sure how it knows
which of the devices behind it a given message is for.
Ideas?Hi
Which version of SQL Server is on the telephony management system? At a
guess it is MSDE with no network protocols installed! Use svrnetcn.exe to
enable the network protcols. If they are running you may want to use the
SQLRecon tool to see what servers are available on your network
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=26
John
"Ellen K" wrote:
> Hi all,
> We have standardized on Hyperion as our reporting tool. So far I have
> only set up a couple of Access databases as data sources for it. Now
> there is a request to report off our eOn (telephony management) SQL
> Server database using Hyperion. The eOn SQL Server box is in a
> workgroup that is not part of the rest of our domain. (We only have
> one domain because we don't have a "forest", whatever that means.) It
> is behind a router owned by eOn along with a PBX and some other stuff.
>
> Setting up a data source for Hyperion requires creating a special data
> source file called an .oce on the box where the Hyperion fat client
> (required for most administrative tasks) resides, and also setting up a
> different special data source file called a .das on the server where
> the Hyperion services run. (The analysts and end-users do not have the
> fat client, their access is web-based.)
> I have to register the eOn SQL Server by using the IP address and SQL
> Server authentication. (I was told that I can't use Windows
> authentication because it is not in the domain.) From the box on
> which the Hyperion fat client resides, I cannot register the eOn SQL
> Server. The error message is "timeout expired". Tracerting indicates
> there are no intermediate hops when attempting to connect from this
> VLAN. From my desktop, which is on a different VLAN, I can connect to
> and register it. This trip includes one hop at our 6509. From one of
> my servers which is on the same VLAN as the fat-client box, I am able
> to connect and register. On the fat-client box I tried deleting and
> re-registering another SQL Server and there was no problem.
> The IP address I have to use to connect to the eOn SQL Server is *NOT*
> the actual IP address of the box it resides on, but rather the eOn
> router, which translates it to the address of the server. We have no
> control over this, eOn creates this setup. I'm not sure how it knows
> which of the devices behind it a given message is for.
> Ideas?
>|||Hi John,
Thanks for your response. I will check the version and also check
which network protocols are enabled on it, assuming I can get to the
box. But if the problem were no network protocols installed on the eOn
box then how would the other two boxes that CAN register it be able to
do so?
Thanks,
Ellen|||Hi
I hadn't realised that it could be registered elsewhere! This indicates that
there are network protocols, but they still may not be the same as the ones
on the client that can't register!! You may still want to try running
SQLRecon and also try to telnet into the port being used.
John
"Ellen K" wrote:
> Hi John,
> Thanks for your response. I will check the version and also check
> which network protocols are enabled on it, assuming I can get to the
> box. But if the problem were no network protocols installed on the eOn
> box then how would the other two boxes that CAN register it be able to
> do so?
> Thanks,
> Ellen
>|||Hi John,
Yes, I mentioned in my original post that I could register it from both
my desktop and from one of "my" servers.
The network protocols are the same on the eOn box as on "my" servers:
named pipes and tcp. Since the fat client can connect to "my" servers,
I think it's safe to say this isn't the problem.
I have now succeeded in creating an ODBC connection, which would not
have been my first choice, but right now if it works I'm happy.
Thanks,
Ellen
registering SQL Server not in domain
Hi all,
We have standardized on Hyperion as our reporting tool. So far I have
only set up a couple of Access databases as data sources for it. Now
there is a request to report off our eOn (telephony management) SQL
Server database using Hyperion. The eOn SQL Server box is in a
workgroup that is not part of the rest of our domain. (We only have
one domain because we don't have a "forest", whatever that means.) It
is behind a router owned by eOn along with a PBX and some other stuff.
Setting up a data source for Hyperion requires creating a special data
source file called an .oce on the box where the Hyperion fat client
(required for most administrative tasks) resides, and also setting up a
different special data source file called a .das on the server where
the Hyperion services run. (The analysts and end-users do not have the
fat client, their access is web-based.)
I have to register the eOn SQL Server by using the IP address and SQL
Server authentication. (I was told that I can't use Windows
authentication because it is not in the domain.) From the box on
which the Hyperion fat client resides, I cannot register the eOn SQL
Server. The error message is "timeout expired". Tracerting indicates
there are no intermediate hops when attempting to connect from this
VLAN. From my desktop, which is on a different VLAN, I can connect to
and register it. This trip includes one hop at our 6509. From one of
my servers which is on the same VLAN as the fat-client box, I am able
to connect and register. On the fat-client box I tried deleting and
re-registering another SQL Server and there was no problem.
The IP address I have to use to connect to the eOn SQL Server is *NOT*
the actual IP address of the box it resides on, but rather the eOn
router, which translates it to the address of the server. We have no
control over this, eOn creates this setup. I'm not sure how it knows
which of the devices behind it a given message is for.
Ideas?
Hi
Which version of SQL Server is on the telephony management system? At a
guess it is MSDE with no network protocols installed! Use svrnetcn.exe to
enable the network protcols. If they are running you may want to use the
SQLRecon tool to see what servers are available on your network
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=26
John
"Ellen K" wrote:
> Hi all,
> We have standardized on Hyperion as our reporting tool. So far I have
> only set up a couple of Access databases as data sources for it. Now
> there is a request to report off our eOn (telephony management) SQL
> Server database using Hyperion. The eOn SQL Server box is in a
> workgroup that is not part of the rest of our domain. (We only have
> one domain because we don't have a "forest", whatever that means.) It
> is behind a router owned by eOn along with a PBX and some other stuff.
>
> Setting up a data source for Hyperion requires creating a special data
> source file called an .oce on the box where the Hyperion fat client
> (required for most administrative tasks) resides, and also setting up a
> different special data source file called a .das on the server where
> the Hyperion services run. (The analysts and end-users do not have the
> fat client, their access is web-based.)
> I have to register the eOn SQL Server by using the IP address and SQL
> Server authentication. (I was told that I can't use Windows
> authentication because it is not in the domain.) From the box on
> which the Hyperion fat client resides, I cannot register the eOn SQL
> Server. The error message is "timeout expired". Tracerting indicates
> there are no intermediate hops when attempting to connect from this
> VLAN. From my desktop, which is on a different VLAN, I can connect to
> and register it. This trip includes one hop at our 6509. From one of
> my servers which is on the same VLAN as the fat-client box, I am able
> to connect and register. On the fat-client box I tried deleting and
> re-registering another SQL Server and there was no problem.
> The IP address I have to use to connect to the eOn SQL Server is *NOT*
> the actual IP address of the box it resides on, but rather the eOn
> router, which translates it to the address of the server. We have no
> control over this, eOn creates this setup. I'm not sure how it knows
> which of the devices behind it a given message is for.
> Ideas?
>
|||Hi John,
Thanks for your response. I will check the version and also check
which network protocols are enabled on it, assuming I can get to the
box. But if the problem were no network protocols installed on the eOn
box then how would the other two boxes that CAN register it be able to
do so?
Thanks,
Ellen
|||Hi
I hadn't realised that it could be registered elsewhere! This indicates that
there are network protocols, but they still may not be the same as the ones
on the client that can't register!! You may still want to try running
SQLRecon and also try to telnet into the port being used.
John
"Ellen K" wrote:
> Hi John,
> Thanks for your response. I will check the version and also check
> which network protocols are enabled on it, assuming I can get to the
> box. But if the problem were no network protocols installed on the eOn
> box then how would the other two boxes that CAN register it be able to
> do so?
> Thanks,
> Ellen
>
|||Hi John,
Yes, I mentioned in my original post that I could register it from both
my desktop and from one of "my" servers.
The network protocols are the same on the eOn box as on "my" servers:
named pipes and tcp. Since the fat client can connect to "my" servers,
I think it's safe to say this isn't the problem.
I have now succeeded in creating an ODBC connection, which would not
have been my first choice, but right now if it works I'm happy.
Thanks,
Ellen
We have standardized on Hyperion as our reporting tool. So far I have
only set up a couple of Access databases as data sources for it. Now
there is a request to report off our eOn (telephony management) SQL
Server database using Hyperion. The eOn SQL Server box is in a
workgroup that is not part of the rest of our domain. (We only have
one domain because we don't have a "forest", whatever that means.) It
is behind a router owned by eOn along with a PBX and some other stuff.
Setting up a data source for Hyperion requires creating a special data
source file called an .oce on the box where the Hyperion fat client
(required for most administrative tasks) resides, and also setting up a
different special data source file called a .das on the server where
the Hyperion services run. (The analysts and end-users do not have the
fat client, their access is web-based.)
I have to register the eOn SQL Server by using the IP address and SQL
Server authentication. (I was told that I can't use Windows
authentication because it is not in the domain.) From the box on
which the Hyperion fat client resides, I cannot register the eOn SQL
Server. The error message is "timeout expired". Tracerting indicates
there are no intermediate hops when attempting to connect from this
VLAN. From my desktop, which is on a different VLAN, I can connect to
and register it. This trip includes one hop at our 6509. From one of
my servers which is on the same VLAN as the fat-client box, I am able
to connect and register. On the fat-client box I tried deleting and
re-registering another SQL Server and there was no problem.
The IP address I have to use to connect to the eOn SQL Server is *NOT*
the actual IP address of the box it resides on, but rather the eOn
router, which translates it to the address of the server. We have no
control over this, eOn creates this setup. I'm not sure how it knows
which of the devices behind it a given message is for.
Ideas?
Hi
Which version of SQL Server is on the telephony management system? At a
guess it is MSDE with no network protocols installed! Use svrnetcn.exe to
enable the network protcols. If they are running you may want to use the
SQLRecon tool to see what servers are available on your network
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=26
John
"Ellen K" wrote:
> Hi all,
> We have standardized on Hyperion as our reporting tool. So far I have
> only set up a couple of Access databases as data sources for it. Now
> there is a request to report off our eOn (telephony management) SQL
> Server database using Hyperion. The eOn SQL Server box is in a
> workgroup that is not part of the rest of our domain. (We only have
> one domain because we don't have a "forest", whatever that means.) It
> is behind a router owned by eOn along with a PBX and some other stuff.
>
> Setting up a data source for Hyperion requires creating a special data
> source file called an .oce on the box where the Hyperion fat client
> (required for most administrative tasks) resides, and also setting up a
> different special data source file called a .das on the server where
> the Hyperion services run. (The analysts and end-users do not have the
> fat client, their access is web-based.)
> I have to register the eOn SQL Server by using the IP address and SQL
> Server authentication. (I was told that I can't use Windows
> authentication because it is not in the domain.) From the box on
> which the Hyperion fat client resides, I cannot register the eOn SQL
> Server. The error message is "timeout expired". Tracerting indicates
> there are no intermediate hops when attempting to connect from this
> VLAN. From my desktop, which is on a different VLAN, I can connect to
> and register it. This trip includes one hop at our 6509. From one of
> my servers which is on the same VLAN as the fat-client box, I am able
> to connect and register. On the fat-client box I tried deleting and
> re-registering another SQL Server and there was no problem.
> The IP address I have to use to connect to the eOn SQL Server is *NOT*
> the actual IP address of the box it resides on, but rather the eOn
> router, which translates it to the address of the server. We have no
> control over this, eOn creates this setup. I'm not sure how it knows
> which of the devices behind it a given message is for.
> Ideas?
>
|||Hi John,
Thanks for your response. I will check the version and also check
which network protocols are enabled on it, assuming I can get to the
box. But if the problem were no network protocols installed on the eOn
box then how would the other two boxes that CAN register it be able to
do so?
Thanks,
Ellen
|||Hi
I hadn't realised that it could be registered elsewhere! This indicates that
there are network protocols, but they still may not be the same as the ones
on the client that can't register!! You may still want to try running
SQLRecon and also try to telnet into the port being used.
John
"Ellen K" wrote:
> Hi John,
> Thanks for your response. I will check the version and also check
> which network protocols are enabled on it, assuming I can get to the
> box. But if the problem were no network protocols installed on the eOn
> box then how would the other two boxes that CAN register it be able to
> do so?
> Thanks,
> Ellen
>
|||Hi John,
Yes, I mentioned in my original post that I could register it from both
my desktop and from one of "my" servers.
The network protocols are the same on the eOn box as on "my" servers:
named pipes and tcp. Since the fat client can connect to "my" servers,
I think it's safe to say this isn't the problem.
I have now succeeded in creating an ODBC connection, which would not
have been my first choice, but right now if it works I'm happy.
Thanks,
Ellen
registering SQL Server not in domain
Hi all,
We have standardized on Hyperion as our reporting tool. So far I have
only set up a couple of Access databases as data sources for it. Now
there is a request to report off our eOn (telephony management) SQL
Server database using Hyperion. The eOn SQL Server box is in a
workgroup that is not part of the rest of our domain. (We only have
one domain because we don't have a "forest", whatever that means.) It
is behind a router owned by eOn along with a PBX and some other stuff.
Setting up a data source for Hyperion requires creating a special data
source file called an .oce on the box where the Hyperion fat client
(required for most administrative tasks) resides, and also setting up a
different special data source file called a .das on the server where
the Hyperion services run. (The analysts and end-users do not have the
fat client, their access is web-based.)
I have to register the eOn SQL Server by using the IP address and SQL
Server authentication. (I was told that I can't use Windows
authentication because it is not in the domain.) From the box on
which the Hyperion fat client resides, I cannot register the eOn SQL
Server. The error message is "timeout expired". Tracerting indicates
there are no intermediate hops when attempting to connect from this
VLAN. From my desktop, which is on a different VLAN, I can connect to
and register it. This trip includes one hop at our 6509. From one of
my servers which is on the same VLAN as the fat-client box, I am able
to connect and register. On the fat-client box I tried deleting and
re-registering another SQL Server and there was no problem.
The IP address I have to use to connect to the eOn SQL Server is *NOT*
the actual IP address of the box it resides on, but rather the eOn
router, which translates it to the address of the server. We have no
control over this, eOn creates this setup. I'm not sure how it knows
which of the devices behind it a given message is for.
Ideas?From your description I pulled this sentence.
"From my desktop, which is on a different VLAN, I can connect to
and register it."
This indicates that you have a valid SQL login, password, protocol, and ip
address. Analyse you desktop and figure out what these are. In particular
the protocol.
The protocol, Network routing, and possibly the firewall will be the issue.
The two most common protocols for SQL is Named Pipes and TCP.
If you can get to the SQL Server from your desktop, look at the SQL Server
Log for what protocols are supported.
From the Hyperion services server use this information to configure an ODBC
DSN and test the connection. You may want to install the SQL client only
option on your Hyperion server to give you more control over the connection
setup (AKA a SQL Alias)
"Ellen K" <ekaye2002@.yahoo.com> wrote in message
news:1129150328.960539.76600@.g47g2000cwa.googlegro ups.com...
> Hi all,
> We have standardized on Hyperion as our reporting tool. So far I have
> only set up a couple of Access databases as data sources for it. Now
> there is a request to report off our eOn (telephony management) SQL
> Server database using Hyperion. The eOn SQL Server box is in a
> workgroup that is not part of the rest of our domain. (We only have
> one domain because we don't have a "forest", whatever that means.) It
> is behind a router owned by eOn along with a PBX and some other stuff.
>
> Setting up a data source for Hyperion requires creating a special data
> source file called an .oce on the box where the Hyperion fat client
> (required for most administrative tasks) resides, and also setting up a
> different special data source file called a .das on the server where
> the Hyperion services run. (The analysts and end-users do not have the
> fat client, their access is web-based.)
> I have to register the eOn SQL Server by using the IP address and SQL
> Server authentication. (I was told that I can't use Windows
> authentication because it is not in the domain.) From the box on
> which the Hyperion fat client resides, I cannot register the eOn SQL
> Server. The error message is "timeout expired". Tracerting indicates
> there are no intermediate hops when attempting to connect from this
> VLAN. From my desktop, which is on a different VLAN, I can connect to
> and register it. This trip includes one hop at our 6509. From one of
> my servers which is on the same VLAN as the fat-client box, I am able
> to connect and register. On the fat-client box I tried deleting and
> re-registering another SQL Server and there was no problem.
> The IP address I have to use to connect to the eOn SQL Server is *NOT*
> the actual IP address of the box it resides on, but rather the eOn
> router, which translates it to the address of the server. We have no
> control over this, eOn creates this setup. I'm not sure how it knows
> which of the devices behind it a given message is for.
> Ideas?|||Hi,
Thanks very much for your response. :)
I think network routing has been eliminated as the cause because I was
able to register the eOn server from one of "my" SQL Servers which is
on the same VLAN as the fat client box that can't register it. And it
can't be a firewall issue because the eOn box is behind our firewall,
it's just not in our domain. I did not think to check the protocols,
that is definitely worth a try. It did occur to me to set up the eOn
database as an ODBC connection for Hyperion instead of using the SQL
Server option, which if it works would solve the current problem.
However, I am also concerned because I am meanwhile building a data
warehouse in SQL Server for which Hyperion is supposed to be the
reporting tool and I would hate to have make a choice that I know up
front is going to diminish performance.
Thanks again, I will report back.
Ellen|||Hi again,
Well, it's not the network protocols.
I did notice that the eOn box is running the original version of SQL
Server, i.e. no service packs have been applied. I will take care of
that, but would be surprised if it's causing the problem.
Meanwhile I did succeed in setting up an ODBC connection, so I've
solved my immediate problem.
Thanks again,
Ellen
registering SQL Server not in domain
Hi all,
We have standardized on Hyperion as our reporting tool. So far I have
only set up a couple of Access databases as data sources for it. Now
there is a request to report off our eOn (telephony management) SQL
Server database using Hyperion. The eOn SQL Server box is in a
workgroup that is not part of the rest of our domain. (We only have
one domain because we don't have a "forest", whatever that means.) It
is behind a router owned by eOn along with a PBX and some other stuff.
Setting up a data source for Hyperion requires creating a special data
source file called an .oce on the box where the Hyperion fat client
(required for most administrative tasks) resides, and also setting up a
different special data source file called a .das on the server where
the Hyperion services run. (The analysts and end-users do not have the
fat client, their access is web-based.)
I have to register the eOn SQL Server by using the IP address and SQL
Server authentication. (I was told that I can't use Windows
authentication because it is not in the domain.) From the box on
which the Hyperion fat client resides, I cannot register the eOn SQL
Server. The error message is "timeout expired". Tracerting indicates
there are no intermediate hops when attempting to connect from this
VLAN. From my desktop, which is on a different VLAN, I can connect to
and register it. This trip includes one hop at our 6509. From one of
my servers which is on the same VLAN as the fat-client box, I am able
to connect and register. On the fat-client box I tried deleting and
re-registering another SQL Server and there was no problem.
The IP address I have to use to connect to the eOn SQL Server is *NOT*
the actual IP address of the box it resides on, but rather the eOn
router, which translates it to the address of the server. We have no
control over this, eOn creates this setup. I'm not sure how it knows
which of the devices behind it a given message is for.
Ideas?Hi
Which version of SQL Server is on the telephony management system? At a
guess it is MSDE with no network protocols installed! Use svrnetcn.exe to
enable the network protcols. If they are running you may want to use the
SQLRecon tool to see what servers are available on your network
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=26
John
"Ellen K" wrote:
> Hi all,
> We have standardized on Hyperion as our reporting tool. So far I have
> only set up a couple of Access databases as data sources for it. Now
> there is a request to report off our eOn (telephony management) SQL
> Server database using Hyperion. The eOn SQL Server box is in a
> workgroup that is not part of the rest of our domain. (We only have
> one domain because we don't have a "forest", whatever that means.) It
> is behind a router owned by eOn along with a PBX and some other stuff.
>
> Setting up a data source for Hyperion requires creating a special data
> source file called an .oce on the box where the Hyperion fat client
> (required for most administrative tasks) resides, and also setting up a
> different special data source file called a .das on the server where
> the Hyperion services run. (The analysts and end-users do not have the
> fat client, their access is web-based.)
> I have to register the eOn SQL Server by using the IP address and SQL
> Server authentication. (I was told that I can't use Windows
> authentication because it is not in the domain.) From the box on
> which the Hyperion fat client resides, I cannot register the eOn SQL
> Server. The error message is "timeout expired". Tracerting indicates
> there are no intermediate hops when attempting to connect from this
> VLAN. From my desktop, which is on a different VLAN, I can connect to
> and register it. This trip includes one hop at our 6509. From one of
> my servers which is on the same VLAN as the fat-client box, I am able
> to connect and register. On the fat-client box I tried deleting and
> re-registering another SQL Server and there was no problem.
> The IP address I have to use to connect to the eOn SQL Server is *NOT*
> the actual IP address of the box it resides on, but rather the eOn
> router, which translates it to the address of the server. We have no
> control over this, eOn creates this setup. I'm not sure how it knows
> which of the devices behind it a given message is for.
> Ideas?
>|||Hi John,
Thanks for your response. I will check the version and also check
which network protocols are enabled on it, assuming I can get to the
box. But if the problem were no network protocols installed on the eOn
box then how would the other two boxes that CAN register it be able to
do so?
Thanks,
Ellen|||Hi
I hadn't realised that it could be registered elsewhere! This indicates that
there are network protocols, but they still may not be the same as the ones
on the client that can't register!! You may still want to try running
SQLRecon and also try to telnet into the port being used.
John
"Ellen K" wrote:
> Hi John,
> Thanks for your response. I will check the version and also check
> which network protocols are enabled on it, assuming I can get to the
> box. But if the problem were no network protocols installed on the eOn
> box then how would the other two boxes that CAN register it be able to
> do so?
> Thanks,
> Ellen
>|||Hi John,
Yes, I mentioned in my original post that I could register it from both
my desktop and from one of "my" servers.
The network protocols are the same on the eOn box as on "my" servers:
named pipes and tcp. Since the fat client can connect to "my" servers,
I think it's safe to say this isn't the problem.
I have now succeeded in creating an ODBC connection, which would not
have been my first choice, but right now if it works I'm happy.
Thanks,
Ellen
We have standardized on Hyperion as our reporting tool. So far I have
only set up a couple of Access databases as data sources for it. Now
there is a request to report off our eOn (telephony management) SQL
Server database using Hyperion. The eOn SQL Server box is in a
workgroup that is not part of the rest of our domain. (We only have
one domain because we don't have a "forest", whatever that means.) It
is behind a router owned by eOn along with a PBX and some other stuff.
Setting up a data source for Hyperion requires creating a special data
source file called an .oce on the box where the Hyperion fat client
(required for most administrative tasks) resides, and also setting up a
different special data source file called a .das on the server where
the Hyperion services run. (The analysts and end-users do not have the
fat client, their access is web-based.)
I have to register the eOn SQL Server by using the IP address and SQL
Server authentication. (I was told that I can't use Windows
authentication because it is not in the domain.) From the box on
which the Hyperion fat client resides, I cannot register the eOn SQL
Server. The error message is "timeout expired". Tracerting indicates
there are no intermediate hops when attempting to connect from this
VLAN. From my desktop, which is on a different VLAN, I can connect to
and register it. This trip includes one hop at our 6509. From one of
my servers which is on the same VLAN as the fat-client box, I am able
to connect and register. On the fat-client box I tried deleting and
re-registering another SQL Server and there was no problem.
The IP address I have to use to connect to the eOn SQL Server is *NOT*
the actual IP address of the box it resides on, but rather the eOn
router, which translates it to the address of the server. We have no
control over this, eOn creates this setup. I'm not sure how it knows
which of the devices behind it a given message is for.
Ideas?Hi
Which version of SQL Server is on the telephony management system? At a
guess it is MSDE with no network protocols installed! Use svrnetcn.exe to
enable the network protcols. If they are running you may want to use the
SQLRecon tool to see what servers are available on your network
http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=26
John
"Ellen K" wrote:
> Hi all,
> We have standardized on Hyperion as our reporting tool. So far I have
> only set up a couple of Access databases as data sources for it. Now
> there is a request to report off our eOn (telephony management) SQL
> Server database using Hyperion. The eOn SQL Server box is in a
> workgroup that is not part of the rest of our domain. (We only have
> one domain because we don't have a "forest", whatever that means.) It
> is behind a router owned by eOn along with a PBX and some other stuff.
>
> Setting up a data source for Hyperion requires creating a special data
> source file called an .oce on the box where the Hyperion fat client
> (required for most administrative tasks) resides, and also setting up a
> different special data source file called a .das on the server where
> the Hyperion services run. (The analysts and end-users do not have the
> fat client, their access is web-based.)
> I have to register the eOn SQL Server by using the IP address and SQL
> Server authentication. (I was told that I can't use Windows
> authentication because it is not in the domain.) From the box on
> which the Hyperion fat client resides, I cannot register the eOn SQL
> Server. The error message is "timeout expired". Tracerting indicates
> there are no intermediate hops when attempting to connect from this
> VLAN. From my desktop, which is on a different VLAN, I can connect to
> and register it. This trip includes one hop at our 6509. From one of
> my servers which is on the same VLAN as the fat-client box, I am able
> to connect and register. On the fat-client box I tried deleting and
> re-registering another SQL Server and there was no problem.
> The IP address I have to use to connect to the eOn SQL Server is *NOT*
> the actual IP address of the box it resides on, but rather the eOn
> router, which translates it to the address of the server. We have no
> control over this, eOn creates this setup. I'm not sure how it knows
> which of the devices behind it a given message is for.
> Ideas?
>|||Hi John,
Thanks for your response. I will check the version and also check
which network protocols are enabled on it, assuming I can get to the
box. But if the problem were no network protocols installed on the eOn
box then how would the other two boxes that CAN register it be able to
do so?
Thanks,
Ellen|||Hi
I hadn't realised that it could be registered elsewhere! This indicates that
there are network protocols, but they still may not be the same as the ones
on the client that can't register!! You may still want to try running
SQLRecon and also try to telnet into the port being used.
John
"Ellen K" wrote:
> Hi John,
> Thanks for your response. I will check the version and also check
> which network protocols are enabled on it, assuming I can get to the
> box. But if the problem were no network protocols installed on the eOn
> box then how would the other two boxes that CAN register it be able to
> do so?
> Thanks,
> Ellen
>|||Hi John,
Yes, I mentioned in my original post that I could register it from both
my desktop and from one of "my" servers.
The network protocols are the same on the eOn box as on "my" servers:
named pipes and tcp. Since the fat client can connect to "my" servers,
I think it's safe to say this isn't the problem.
I have now succeeded in creating an ODBC connection, which would not
have been my first choice, but right now if it works I'm happy.
Thanks,
Ellen
Subscribe to:
Posts (Atom)