New domain pc and user can't connect to BCM database outlook 2003

[AL]

Have a small windows sbs domain where we have a BCM database (outlook
2003) on one machine stored locally, the dbase is shared and other
users connect fine.

Added a new machine and new user to the domain and we cant connect to
bcm from this machine. we can use osql to connect from the command
prompt successfully, but when we go into the bcm setup initially it
says no shared databases exist on the other machine.

Appreciate any suggestions...

 

[Luther]

Have a small windows sbs domain where we have a BCM database (outlook
2003) on one machine stored locally, the dbase is shared and other
users connect fine.

Added a new machine and new user to the domain and we cant connect to
bcm from this machine. we can use osql to connect from the command
prompt successfully, but when we go into the bcm setup initially it
says no shared databases exist on the other machine.

Appreciate any suggestions...

Are database and client machine running exactly the same version of
BCM (including same locale)? There's a database table, called
something like org table, where that info is stored and which BCM
queries to decide whether it can connect to a database or not.

 

[Steve]

Are database and client machine running exactly the same version of
BCM (including same locale)? There's a database table, called
something like org table, where that info is stored and which BCM
queries to decide whether it can connect to a database or not.

 

[Steve]

Are database and client machine running exactly the same version of
BCM (including same locale)? There's a database table, called
something like org table, where that info is stored and which BCM
queries to decide whether it can connect to a database or not.

I have exactly the same problem and sounds like the same setup. I have
granted the user access to connect to BCM, arranged access in SQL Server, no
firewall issues as there is an open port for BCM. There are no restrictive
policies from what I can see.
The org table sharing as "1" which I assume is switched on. Other machines
can connect. Does anyone have ideas about this?

 

[Pat@Verus]

I have exactly the same problem and sounds like the same setup. I have
granted the user access to connect to BCM, arranged access in SQL Server, no
firewall issues as there is an open port for BCM. There are no restrictive
policies from what I can see.
The org table sharing as "1" which I assume is switched on. Other machines
can connect. Does anyone have ideas about this?

I am an SQL expert (but not a DBA) recently dragged into a similar problem
for one of our clients. They have a BCM database to which new users cannot
connect, and to which existing users CAN connect, but only until they use the
"connect" feature of the client. Then the database disappears from the list
of available BCM databases, and cannot be connected to after that. Per other
posts related to this problem, especially from "Luther" it seems clear that
the client uses values (version and locale) in OrgTable to recognize a
database as a valid BCM database. Further, once recognition and connection
happen, it seems clear that the client saves LOCAL info about that database
(in a config file? an Outlook folder? the Registry?) so it can connect to
it by default when Outlook is re-launched - and it is pretty obvious that in
that particular reconnect exercise, it does NOT bother to recheck the
OrgTable attributes - otherwise the connection-to-default-on-launch would
fail, but it does not. As mentioned, this remains successful for existing
clients/users as long as they have not clicked the "Connect" button to look
for a different BCM database. The database that gives us problems exists,
the client machines can see the host SQL Server instance and the database
itself using other tools and approaches. There are no problems with SQL
permissions, ports or listeners. The client machines can also see other BCM
databases created newly on the server instance. Our problem, like many other
posters, is clearly related to an inability of the client to recognize the
BCM database as such.

What is needed from Microsoft is a document CLEARLY explaining the use of
OrgTable and any other database attributes in this
recognition-of-a-database-as-a-BCM-database process. In addition, any other
usage of values in the OrgTable should be enumerated. I hesitate to update
the values in that table in case they cross-reference with other factors,
such as counts of contacts, etc.

Our locales are correct, but it's not clear why changing a client version
should invalidate that client's ability to "see" a pre-existing shared BCM
database - but if that is the case, then it sounds like all clients in a
shared environment must be on the same version of BCM to effectively share a
single BCM database. In any case, if Luther or anyone else very familiar
with the new connection process could set up some clear documentation of it,
I'm sure a great number of us could save a lot of time engaging in these
particular posts...

Thanks in advance...

 

[Luther]

I am an SQL expert (but not a DBA) recently dragged into a similar problem
for one of our clients.   They have a BCM database to which new users cannot
connect, and to which existing users CAN connect, but only until they usethe
"connect" feature of the client.  Then the database disappears from thelist
of available BCM databases, and cannot be connected to after that.  Perother
posts related to this problem, especially from "Luther" it seems clear that
the client uses values (version and locale) in OrgTable to recognize a
database as a valid BCM database. Further, once recognition and connection
happen, it seems clear that the client saves LOCAL info about that database
(in a config file? an Outlook folder?  the Registry?) so it can connect to
it by default when Outlook is re-launched - and it is pretty obvious thatin
that particular reconnect exercise, it does NOT bother to recheck the
OrgTable attributes - otherwise the connection-to-default-on-launch would
fail, but it does not.  As mentioned, this remains successful for existing
clients/users as long as they have not clicked the "Connect" button to look
for a different BCM database.  The database that gives us problems exists,
the client machines can see the host SQL Server instance and the database
itself using other tools and approaches. There are no problems with SQL
permissions, ports or listeners.  The client machines can also see other BCM
databases created newly on the server instance.  Our problem, like manyother
posters, is clearly related to an inability of the client to recognize the
BCM database as such.

What is needed from Microsoft is a document CLEARLY explaining the use of
OrgTable and any other database attributes in this
recognition-of-a-database-as-a-BCM-database process.   In addition, anyother
usage of values in the OrgTable should be enumerated.  I hesitate to update
the values in that table in case they cross-reference with other factors,
such as counts of contacts, etc.  

Our locales are correct, but it's not clear why changing a client version
should invalidate that client's ability to "see" a pre-existing shared BCM
database - but if that is the case, then it sounds like all clients in a
shared environment must be on the same version of BCM to effectively share a
single BCM database.  In any case, if Luther or anyone else very familiar
with the new connection process could set up some clear documentation of it,
I'm sure a great number of us could save a lot of time engaging in these
particular posts...

Thanks in advance...- Hide quoted text -

- Show quoted text -

I'm familar with one thing, where the client stores information about
which database it is connected to.

It's stored in the Outlook Profile. If you go to the Control Panel
Mail applet, there you can edit the Outlook Mail profiles, and BCM
database is one of the properties of the profile. You can remove and
add BCM database to a profile. Add ing a BCM database brings up the
same UI you get in BCM when you select or create a new database.