Discussion:
[mapguide-users] Fwd: [OSGeo-Discuss] Why does OSGeo FDO Provider for SQL Server Spatial try to access the wrong database?
Johan Van de Wauw
12 years ago
Permalink
Nathan,

You are more likely to get good answers on the mapguide
mailinglist(I'm forwarding your mail).

Johan.

---------- Forwarded message ----------
From: Nathan Deneau <***@asu.edu>
Date: Wed, Sep 18, 2013 at 10:00 PM
Subject: RE: [OSGeo-Discuss] Why does OSGeo FDO Provider for SQL
Server Spatial try to access the wrong database?
To: Johan Van de Wauw <***@gmail.com>
Cc: "***@lists.osgeo.org" <***@lists.osgeo.org>


Yes, AutoCAD Map 3D, sorry. The login that accesses the spatial
database from AutoCad Map 3D using the same FDO provider has server
admin privileges so he would not receive the same error. This is a SQL
Server host with many databases so the administrators will not want to
grant me access beyond read access. How do I accomplish this given the
following facts?

All user logins belong to the public role and cannot be removed from
the public role in MS SQL Server. The public role has "VIEW ANY
DATABASE" permission by default in MS SQL Server. So that means we can
always expect the default behavior of a login to be able to see all
databases even if that user cannot read (select) from all of those
databases. I was hoping that the FDO provider would ignore any
databases that it can see but not read from and simply move on to the
next database in the list eventually finding any databases that the
login does have permission to read and accumulating them - or at least
either honor the default database of the user login or else allow an
option to ignore all but a specified database.

The error in my FDO connection test seems to show that it is trying to
connect to these other databases and crashes when my login does not
have permissions and throws the error I included in my previous post.
So I have to assume that there is a more narrow set of allowable
configurations of SQL Server, the FDO provider, or Autodesk Studio
(e.g. not allowed to have other databases my login can't read on the
host, must change public role which potentially affects everyone else
on the shared host, must share a user account with owner privileges,
must specify a database for the OSGeo FDO provider for SQL Serve
Spatial somewhere, must set Autodesk Studio setting somewhere to
specify the one spatial database).

Thank You,

Nathan


-----Original Message-----
From: Johan
Sent: Tuesday, September 17, 2013 11:40 PM
To: Nathan
Subject: Re: [OSGeo-Discuss] Why does OSGeo FDO Provider for SQL
Server Spatial try to access the wrong database?
- The author of the SQL Server Spatial database is able to access the
geometry from other products (AutoCad I believe).
If it really is AutoCAD he probably means AutoCAD Map or Civil 3D. In
that case he can export a map to mapguide or autodesk infrastructure
map server by choosing file\publish\publish to map server.

This will copy the exact settings that were used in autocad.

But I think the error is rather due to MS SQL security settings. Are
you using the same username/password in both cases?
- I can see other database names from Microsoft SQL Management Studio
but I do not have permissions to view any details about these databases.
- The first database listed in the databases names I can see is the
"WrongDatabaseNotMyDefault" database from the error - the default
database for my login is the thirteenth (13th) database down the list!
Thanks For Your Help,
Nathan
_______________________________________________
Discuss mailing list
http://lists.osgeo.org/mailman/listinfo/discuss
GordonL
12 years ago
Permalink
Just to confirm, I cannot use SQL Server provider for FDO if the user cannot
connect to all databases on the server.
Total pain, and sometimes, depending on IT department, a 'show stopper'.

Expected behavior, only need to give access to the database the FDO is
using.

Gordon



--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Fwd-OSGeo-Discuss-Why-does-OSGeo-FDO-Provider-for-SQL-Server-Spatial-try-to-access-the-wrong-databas-tp5078593p5079111.html
Sent from the MapGuide Users mailing list archive at Nabble.com.
Bruno Scott
11 years ago
Permalink
Hi Gordon,
I've just created a new ticket with patch attached that may fixed that
issue.
The patch is trunk based but can be applied on the 3.7 and 3.8 branche
without any problem.

http://trac.osgeo.org/fdo/ticket/876 <http://trac.osgeo.org/fdo/ticket/876>

Bruno



--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Fwd-OSGeo-Discuss-Why-does-OSGeo-FDO-Provider-for-SQL-Server-Spatial-try-to-access-the-wrong-databas-tp5078593p5079445.html
Sent from the MapGuide Users mailing list archive at Nabble.com.
GordonL
11 years ago
Permalink
Cool, any builds available to test?





--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Fwd-OSGeo-Discuss-Why-does-OSGeo-FDO-Provider-for-SQL-Server-Spatial-try-to-access-the-wrong-databas-tp5078593p5079910.html
Sent from the MapGuide Users mailing list archive at Nabble.com.
Bruno Scott
11 years ago
Permalink
There is some HomeMade builds that you could try out.
There are 3 tickets fixed in these build: 766
<http://trac.osgeo.org/fdo/ticket/766> , 876
<http://trac.osgeo.org/fdo/ticket/876> , 875
<http://trac.osgeo.org/fdo/ticket/875>

You can download here

fdo 3.8 x64
<http://www.geomapgis.com/web/geomap-group/fdo/SqlServerSpatial/3.8/x64/SQLServerSpatialProvider.zip>
fdo 3.8 win32
<http://www.geomapgis.com/web/geomap-group/fdo/SqlServerSpatial/3.8/win32/SQLServerSpatialProvider.zip>
fdo 3.7 x64
<http://www.geomapgis.com/web/geomap-group/fdo/SqlServerSpatial/3.7/x64/SQLServerSpatialProvider.zip>
fdo 3.7 win32
<http://www.geomapgis.com/web/geomap-group/fdo/SqlServerSpatial/3.7/win32/SQLServerSpatialProvider.zip>

Bruno



--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Fwd-OSGeo-Discuss-Why-does-OSGeo-FDO-Provider-for-SQL-Server-Spatial-try-to-access-the-wrong-databas-tp5078593p5080148.html
Sent from the MapGuide Users mailing list archive at Nabble.com.
GordonL
10 years ago
Permalink
Bruno, this was a great fix. Unfortunately it never made it into FDO 3.9.
I have to use these 3.8 DLLS (above) for MapGuide 2.6 to work-around the
need to have access to every Database in SQL Server.

Perhaps FDO 3.9?





--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Fwd-OSGeo-Discuss-Why-does-OSGeo-FDO-Provider-for-SQL-Server-Spatial-try-to-access-the-wrong-databas-tp5078593p5170200.html
Sent from the MapGuide Users mailing list archive at Nabble.com.
Crispin_at_Linknode
8 years ago
Permalink
Bump... perhaps for FDO 4.2 ?



--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Fwd-OSGeo-Discuss-Why-does-OSGeo-FDO-Provider-for-SQL-Server-Spatial-try-to-access-the-wrong-databas-tp5078593p5319076.html
Sent from the MapGuide Users mailing list archive at Nabble.com.
Jackie Ng
7 years ago
Permalink
Just necro-ing this thread as I am taking a momentary detour from MapGuide
development to look at some long standing issues with the various FDO
providers (including SQL Server).

Currently, I'm looking at my proposed solution
(https://trac.osgeo.org/fdo/ticket/933) over Bruno's proposed solution
(https://trac.osgeo.org/fdo/ticket/876) because my proposed solution (using
HAS_DBACCESS(name) = 1) is more preventative in nature. We don't have to
try/catch and correct the situation on the right error code if we have the
means to prevent such a situation from happening in the first place, which
HAS_DBACCESS seems to do for us.

With the exception of Azure SQL, HAS_DBACCESS is also supported all the way
back to SQL Server 2008 as well, so this is not some recently introduced
function.

Thoughts?

- Jackie



--
Sent from: http://osgeo-org.1560.x6.nabble.com/MapGuide-Users-f4182607.html
Loading...