Alan and Rob: We have a user group for our staff which we use to apply permissions. We have mapped this user group to the NBNData database and also assigned the database roles of db_datareader, db_datawriter and public to NBNData (see SQL Books Online to see what permissions these grant). Recorder on our network seems to be able to run with only the public role, but I've had discussions with some that can only get Recorder to run if they assign the db_owner role (otherwise they get an EOleException: Login Failed for user 'DOMAIN\User'). Perhaps John could clarify what database roles should be assigned?

John: I've been working on the 'crash on startup issue' today and yes, I found the cause. It's a bit strange, but here's the deal (I'm going to be extra verbose in my description so others can make use of the techniques I've employed):

We created a new restricted user on the network so that we knew their profile was completely 'clean'.

I did a fresh workstation install onto a new laptop logged in as me (an administrator) and confirmed Recorder was working. It was.

I then logged out and logged in as our new restricted user and tried to run Recorder and got the crash.

So, I ran Regmon by right-clicking its .exe and choosing "run as..." then running it under my user account. This is an important step - you need to run regmon under a restricted user account in order to properly analyse what registry write, if any, is causing the crash. The trouble is, Regmon can only be run with admin priviledges, hence the need to 'run as...'

Once running I set Regmon to filter on 'recorder*' and registry writes and errors only.

I tried running Recorder again and voila, I get several ACCESS DENIED registry entries. It's the last one that appears to be causing the crash. Here's the key that Recorder is trying to write to:

HKEY_CLASSES_ROOT\TypeLib\{801EBE82-91CE-11D3-B564-005004B0B698}\1.0\0\win32

And here is what the key already contains:

\\DOMAIN-02\Data$\SWTBRC\Recorder 6 Server\Recorder.ex_

A restricted user doesn't have permission to write to this key in the registry, and so I assume that when it tries to do so, Recorder crashes.

What is odd is that this path is OK. I can CD to \\DOMAIN-02\Data$\SWTBRC\ no problem, so why is Recorder trying to rewrite it?

Further analysis reveals this:

Recorder is installed on our T:\ drive, which is mapped here:

\\domain-02\data$\swtbrc

which is identical apart from the case. Now here's the odd part: if I disconnect the T:\ drive an remap it to:

\\DOMAIN-02\Data$\SWTBRC\

in order to exactly match the existing registry key, then Recorder starts when logged in as the restricted user.

Obviously, the reason this crashing problem kept coming back is because our T:\ drive is getting automatically remapped to its initial, lowercase, path.

I reckon this is probably classed as a bug: Recorder shouldn't be trying to rewrite that registry key simply because it has case differences.

Charles

When you installed Recorder Workstation (as local admin) did you install it from the T drive mapping or the UNC path?  My typelib is registered against the drive mapping so I don't get the problem.

I'm not sure I can do much to fix Recorder on this one because the registration of the type library occurs automatically since Recorder is a COM server.

Hi ,

to resolve the ODBC/ linked Access table error, we have finally got the solution. Yes you're going to yell loudly here...

Make sure you have Access installed on the server.

Then it works

I can now open NBNData.mdb remotely, run queries etc.

It's always the simple things is it not?

Many thanks for all help over the past wee while,

We also may have cracked how to run R6 as a restricted user, will be back after some testing!

Cheers now, Rob.

Hi all - I've been away for a bit, and just picking up on this again now. The first thing I have to confess is that I am very confused about the relationships, when using "Trusted Connection" authenication between Windows Users, database users on SQL Server and "Logins" on SQL Server.

In between cogitating on this I've carried out another fresh install, as Administrator on both client and server machines. Having established Recorder was runing OK from the Admin account on the client machine, I tried running as a) an ordinary User and b) a Power User. In the first instance I get a dialog prompting for  user on the server. Even if I enter an Administrator user here I still get a message "Login failed for user. The user is not associated with a trusted SQL Server connectiuon" If I try to run Recorder as a Power User I am not prompted fro a user on the server, but still get the same login error message.

I'm sorry if I'm missing the answer to all this in postings already made.

Thanks

Alan

Not 100% sure on this. All I know is that our server and workstations are definitely part of the same domain.

Yes.

Yes.

When you map a Windows account or group to a SQL Server login (which grants access to the server), and then map the login to a database (which gives access to the database within the server), you are effectively giving that Windows account (or any account within the Windows group) access to that database. You then assign roles to the login, which grants the user particular privilages within the database, such as db_datareader and db_datawriter. If I've understood you correctly, there isn't an intermediate user created. You can create users within SQL Server, but this is for situations when you're not using a Windows trusted connection. It's better to use Windows trusted if you can; creating and managing users in SQL Server is there as a backup if Windows trusted isn't available for whatever reason.

That's all a bit jumbled so I hope it makes some semblance of sense.

I'm not 100% sure on this either, but I'm fairly certain it's the principal that logs in when you're using standalone, non-trusted authentication. It's one of the SQL Server managed users I referred to above. I'm sure someone from Dorset or JNCC will correct me if I'm wrong, though. :)

Charles

Have been away a few days and just picked up this thread again. It sounds like you are on the right track. To confirm:

1) The NBNUser login is used by Recorder when you don't use the Trusted Connection option. It allows Recorder to get read only access to the data - enough to verify the Recorder user login details and switch on the appropriate level of database access (using Application Roles if anyone is interested).

2) For a network user to be trusted on an SQL Server, there must be a database login set up which fully recognises that user. I don't think it will work in a workgroup environment. If you use more than one domain this is Ok, as you can prefix the username when you set up the database user as follows: DOMAIN\Username.

Alan,

In this case, you are forced to use the default connection type which is not trusted. Then Recorder will create and use its own NBNUser login for authentication, and you will not have to worry about all the connection options discussed in this thread. Its a much easier option which is why its the default.

The main reason for supporting Trusted connections would be if you have an existing SQL Server with a database administrator who does not want additional logins cluttering up the server. They may be used to controlling access to applications through windows logins and trusted connections and would prefer to continue that way. They would be able to prevent users getting into Recorder at all (even if they have a login within the application) so there is an extra level of control through trusted connections.  Having said that I doubt that this is necessary for the vast majority of Recorder users.

My personal recommendation would be to stick to the default option, unless you have a good reason not to and need to use trusted connections.

The installation tool is asking you for a login with System Administrator privileges, which is 'sa' with blank password on a default MSDE install. The NBNUser login is used by Recorder for limited access to the NBNData database, and is a completely different login to the login required for installation which needs admin rights in order to set up the database correctly for you.

Assuming you are using the standard method of authentication (i.e. not trusted) from Recorder, then yes. Also, having done the move you should run the following script to ensure that the database and server versions of the NBNUser account are properly joined:

EXEC sp_change_users_login ‘Update_One’, ‘NBNUser’, ‘NBNUser’

There's is information on this account in the Network Installation Guide on the CD - under the section entitled "Recorder 6 Database Security". Its probably best to read that information before proceeding.

Further to my last posting, I've realised that one of the issues arose from my misinterpretation of one of the install dialog boxes. Thus, I'd assumed the Recorder install defaults the MSDE instance name to "Recorder" (this name remains in the correspoding text box even when "I want to specify my own server instance name" is unchecked - this suggests to me the name defaults to "Recorder").

Anyway, the point still remains that, apparently, the MSDE instance is only found by the workstation if its name is left at default (i.e. no name).

Furthermore, it seems to me that, whether you use Windows authentication or SQL Server authentication, you are probably going to require a domain-based network. It does not seem to be that you can install the Recorder workstation as an administrator and then that any other users on the client will be able to access Recorder (as John V suggested would be the case) unless they are domain registered users. This is because of permissions governing access to the shared folder on the server machine. The only other alternatives I can see is that either you have each Windows user login details duplicated on the server, or have everyone login as the same specific user whose login details are replicated on the server. I suppose either of these options are feasible, if not ideal.

Alan