Hi

I can probably answer some of your Qs

1- you should have no problem with 9.35 client connecting to SQLserver 2008R2 theroretical, I have never ran it, changed the client to TMS2010 when we did the database migration from 2000 to 2008, but I have seen nothing in documentation which would suggest otherwise, you may have to adjust the db compatability level though

2- you can use a domain groups, actualy for a larger organisation, that would be the only viable choice, just see to it that they have the necessary grants/permissions

3- not sure about that, personally I prefer to map the path explicitly and not rely on the drive name that may or may not change due to drive letter being occupied, but it is a matter of preference I guess

4- if you are referring to the database configuration tool that is part of TMS, I think it is part of the client install, I never bothered to get it out of the client installation and in the server, I assume there is some merit to that approach as this would allow some measure of greater security

5- there are some reasons for using a TMS terminal server installation, one would be if you would like to give staff the ability to access TMS while off site, another is ofcourse use of thin clients, third is if anyone insists on using Macs and not use Bootcamp 

Mvh /Mehrdad 

--------------------------------------------------------------------------- 

Mehrdad Ravanbod 
IT/Database Admin               Email: [log in to unmask]
Moderna Museet                  Tel  mobil: 0708 945795, ankn. 5246
Box 16382 
103 27  Stockholm                  

 

-----Ursprungligt meddelande-----
Från: The Museum System (TMS) Users [mailto:[log in to unmask]] För Forrest Smalley
Skickat: den 24 januari 2012 02:05
Till: [log in to unmask]
Ämne: Moving version 9.35 to SQL2008R2 and Remote

Hello,

One of our museums is using TMS 9.35 with SQL 2000 and the "Image Server" file location/share running on the same server(Windows 2003).

To better support the system during a transition period to a new collection system, we would like to migrate the existing system into our supported model of frontend file servers as Virtual Private servers and moving the two databases "TMS", TMSThesaurus" to our shared SQL 2008 R2 instance.

I have read much of the manual, but I may not have full access to their tech support. As an outsider IT person with the central IT department, I have to simply log in, read the manual to see how the system works in the current department. I have a few questions if anyone has done this...

a)I am certain I can restore the dbs to 2008, but I am not sure if there are any compatibility issues with SQL 2008R2 with the front end thick client with version 9.35? (I see the latest version seems to officially support SQL 2008R2)

b)I see maybe dozens of SQL accounts created for users in the existing server...can you use domain accounts or a group instead?  Most perms seem based on tmsadmin not individual users so I am not sure what they are there for really.

c)our current file share is mapped by the clients as \\servername\tmsimages  as Y:\   I see the path mapped in the db in the mediapath/mediafiles tables as Y:.  This leads me to believe that as long as the clients change their ODBC to the new SQL server, and map the new Y: as \\newservername\tmsimages, the client should work fine with no other intervention?

d)it seems that server side, other than an images share and a the actual database engine, there is not much to install other than a "Database configuration" tool which probably will not be used...if I am doing this manually...all backups etc...will fall under our normal schedule. I can install the tool,but I don't see much need for it really...is there a piece that I am missing in this puzzle?

e)Since all clients will stay on current version...I guess I lean towards not switching to a terminal server mode approach at this time on the same server that will be used as the image server...other than one-stop central maintenance of the thick client, is there any other reason to move users to a terminal server approach?

Thanks for any advice/comments/notes you may have to offer.

Forrest
UC Berkeley

To unsubscribe, send an email to [log in to unmask] with the following commands in the body of the email:

     signoff TMSUSERS

     //  eoj


You will receive a confirmation that your subscription has been removed.

To unsubscribe, send an email to [log in to unmask] with the following commands in the body of the email:

     signoff TMSUSERS

     //  eoj


You will receive a confirmation that your subscription has been removed.