Ohh busy day, but thank the Lord, it's nearly punching out time...
Oh here we go a Rockwell employee with an opinion...
I'm not sure where you got the notion that I was a Rockwell employee?
Or that I have an opinion for that matter?
I am simply an Electrician working in a manufacturing environment. Although my employers insist on calling me a Technician, I don't really care, once the pay is good.
...Remember the good old days " did you ground the 1771 chassis with a #6 awg wire? How about a great product called interchange (before rslinx) yah Tech connect really helped there...
That chip on your shoulder really does go back a long way? The phone support, then and now, does leave a lot to be desired, depending on who you get, but the Knowledgebase has plenty of useful information.
...I have found that If you know little about Rockwell products you will have a steep learning curve...
That is quite true. Having never worked for them, I have learned whatever little I know the hard way. Through experience, determination, lots of reading, and with the help of Rockwell, their Knowledgebase, and the good people of this Forum.
...Anyway this is not the thread for your employment issues...
Also true. I don't have any. I'm perfectly happy in my current role.
...Oh by the way are you perhaps data mining yourself, looking for answers that will become tech notes for Rockwell, or are you using this site to see what hardware / Software issues there are. May I suggest that you spend some time with the Micro800 you can spend weeks on this product line...
Actually no, I'm not. But if they were willing to pay me, perhaps I might consider it? What I am doing here is trying to help people, in return for the many years of help I have received, directly or indirectly.
...For all the people who want to know the answer. I ended up installing Factory talk entirely on a 32 bit computer running windows 7.0...I think my issue was that I tried to open a 32 bit file with a 64 bit machine...I think that if the program came from a windows XP environment stay with 32 bit operating system is the answer...
Now that you have gotten sorted, one way or another, I don't see the harm in explaining this...
You ended up finding a solution, yes, but possibly not the simplest one? The fact you opened an application, created under a 32-bit OS, in FTVS, under a 64-bit OS, is precisely what was wrong.
1. FactoryTalk View Studio v5.0, and newer, introduced the ability to restore MER runtime files back to development files (MED). FTVS v5.0 - v6.0 are only compatible with 32-bit OS.
2. Applications developed within FTVS v5.0 - v6.0, under a 32-bit OS, use the older 32-bit WATCOM tag database, and not the newer Microsoft SQL Server. MSSQL replaced the WATCOM tag database at FTVS v6.10.
3. While MSSQL supports both 32-bit and 64-bit OS, FTVS only uses the 32-bit version of MSSQL. This is the version that is installed whether FTVS v6.10 is installed under a 32-bit or 64-bit OS.
4. When FactoryTalk View Studio v6.10 is installed under a 32-bit OS, both the 32-bit WATCOM tag database, and the 32-bit MSSQL Server are installed. This allows for forward and backward compatibility between pre v6.10 and post v6.10 applications.
5. When FactoryTalk View Studio v6.10 is installed under a 64-bit OS, only the 32-bit MSSQL Server is installed. The 32-bit WATCOM tag database is not compatible under a 64-bit OS.
6. An MER runtime file, created in FTVS v5.0 - v6.0, under a 32-bit OS, that was set to "Allow" for the "Convert to Development" setting, will add the 32-bit WATCOM database into the MER file, so as it can be restored later.
7. To restore this MER back to an MED, you must do so using the Application Manager under a 32-bit OS, where FTVS and the 32-bit WATCOM database is also installed. This allows a successful restoration of the MER and the tag database.
8. Attempting to restore an MER runtime file, created in FTVS v5.0 - v6.0, under a 32-bit OS, by using the Application Manager under a 64-bit OS, can result in corrupting the 32-bit MSSQL Server instance "FTVIEWX64TAGDB".
9. To restore the corrupted "FTVIEWX64TAGDB" instance, all you needed do was replace a certain two files under the aforementioned "MSSQL10_50.FTVIEWX64TAGDB" folder, with the same named files under another close by folder, and reboot.
10. To restore and use MER files, created in FTVS v5.0 - v6.0, under a 32-bit OS, as per No.7 above, you can use XP Mode within Windows 7 Professional, which you mentioned you have. This would save you installing to a separate computer all together. This way, you can use one computer to work on new and legacy applications.
...My customer wanted to know the Log in password, this is one of the reasons why I wanted to look at the MER file. I was able to add myself as an administrator and the log in appears now to be working with my computer password...
I'm actually glad you got something working for them, one way or the other, in the end. But for your information in regard to acquiring passwords from existing user accounts, within an existing FTVME application...
FTV does not actually store the password as typed, but rather a "hash" of the password. When you create a password, it generates an encrypted hash of it, and stores that hash value. When you type in a password, it too is similarly encrypted to a hash value and then compared to the encrypted hash it has stored. If they match, it knows you entered the same password and permits you to log in. If the encrypted hash values do not match, you know the rest. So, the original password, as typed, is not actually stored, so there is no way for someone else to acquire the actual password, as typed.
Now some might complain..."But that's silly?"..."what if I, or a customer forgets their password?"
Well, think of the alternative scenario..."Hey, someone hacked my password!...or my customers password!"..."FT Security sucks!"
I know which I prefer.
Regards,
Non-Rockwell Employee
