awalkinthepark
asked on
Goldmine 5.7 moved to a new server. update contsupp cannot find attachments
A server died.
Moved SQL database to a new machine from backups
reinstalled GM
bdeadmin configured
Can log in to Goldmine ( from the same machine )
Haven't checked everything yet, but it looks more or less ok.
In SQL manager, I updated consupp records where the path to the attachments is specified.
(where rectype = 'L' , updated address1 )
It can find email without an attachment right away.
When I try to view an email that has an attachment it takes a minute or so then shows the email with no attachment. I think it is trying to find the attachment during this wait.
The path I have set in the address1 field in contsupp is correct.
( pasting address1 + address2 into windows explorer, the attachments are found. )
What else could be involved that is causing the failure to find the attachments
Thanks
Moved SQL database to a new machine from backups
reinstalled GM
bdeadmin configured
Can log in to Goldmine ( from the same machine )
Haven't checked everything yet, but it looks more or less ok.
In SQL manager, I updated consupp records where the path to the attachments is specified.
(where rectype = 'L' , updated address1 )
It can find email without an attachment right away.
When I try to view an email that has an attachment it takes a minute or so then shows the email with no attachment. I think it is trying to find the attachment during this wait.
The path I have set in the address1 field in contsupp is correct.
( pasting address1 + address2 into windows explorer, the attachments are found. )
What else could be involved that is causing the failure to find the attachments
Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hi ,
Your SQL update will only update the Links tab records.
There are other records to consider, Templates, KB links, Reports.
The Email attackments are actually links to the file encoded in the MAILBOX records (RFC822 field) and you will have a serious problem updating them with SQL directly
As Steven has mentioned you need to use the linkdoc tool, you will do well to restore the database before you CONTSUPP records updates before you start.
The linkdoc tool works very well and I always use it for just this very task.
One suggestion though, if your goldmine installation was working via a mapped drive letter, then all you would need to do is map the same drive letter to the new server and no rename would be needed.
If however you where using UNC paths then you will have no choice but to run the linkdoc tool.
Your SQL update will only update the Links tab records.
There are other records to consider, Templates, KB links, Reports.
The Email attackments are actually links to the file encoded in the MAILBOX records (RFC822 field) and you will have a serious problem updating them with SQL directly
As Steven has mentioned you need to use the linkdoc tool, you will do well to restore the database before you CONTSUPP records updates before you start.
The linkdoc tool works very well and I always use it for just this very task.
One suggestion though, if your goldmine installation was working via a mapped drive letter, then all you would need to do is map the same drive letter to the new server and no rename would be needed.
If however you where using UNC paths then you will have no choice but to run the linkdoc tool.
ASKER
I'm sure the tool would work fine when both the old and new location are available.
I did have to move the DB a year ago, and manually updated the paths and it worked.
This time something else seems to be involved.
I restored the database, the only thing that was updated was the path in address1.
If the file is in the database encoded (RFC822 ) then that doesn't have to move.
The file attachment is also in the OS filing system in the mailbox folder under the user name.
"The Email attackments are actually links to the file encoded in the MAILBOX records (RFC822 field) "
The file itself is encoded and saved as a blob or the path is encoded?
"The Email attackments are actually links to the file encoded in the MAILBOX records (RFC822 field) "
Changing the paths in address1 and doing nothing with RFC822 worked before.
Why would changing the path from an invalid one to a valid one cause a problem?
What else is involved?
I'm not going to re-restore the DB, users are already back on it, and if anything I could simply
change the address1 path back to the invalid path to the dead server and try the tool again, but that sounds ridiculous.
Considering the points I made above, does that change your thoughts on how to proceed?
Thanks again for your help
I did have to move the DB a year ago, and manually updated the paths and it worked.
This time something else seems to be involved.
I restored the database, the only thing that was updated was the path in address1.
If the file is in the database encoded (RFC822 ) then that doesn't have to move.
The file attachment is also in the OS filing system in the mailbox folder under the user name.
"The Email attackments are actually links to the file encoded in the MAILBOX records (RFC822 field) "
The file itself is encoded and saved as a blob or the path is encoded?
"The Email attackments are actually links to the file encoded in the MAILBOX records (RFC822 field) "
Changing the paths in address1 and doing nothing with RFC822 worked before.
Why would changing the path from an invalid one to a valid one cause a problem?
What else is involved?
I'm not going to re-restore the DB, users are already back on it, and if anything I could simply
change the address1 path back to the invalid path to the dead server and try the tool again, but that sounds ridiculous.
Considering the points I made above, does that change your thoughts on how to proceed?
Thanks again for your help
I'm not going to re-restore the DB, users are already back on it, and if anything I could simply
change the address1 path back to the invalid path to the dead server and try the tool again, but that sounds ridiculous.
=============
That's your best option. Everything else is, in the final analysis, more difficult.
change the address1 path back to the invalid path to the dead server and try the tool again, but that sounds ridiculous.
=============
That's your best option. Everything else is, in the final analysis, more difficult.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
so, seems that it's about the paths to the attachments.
I'm talking about attached doc and excel files.
These seem to be all correctly entered in to the contsupp table in the address1 field,
yet they are not found. Perhaps permissions on the mailbox folders (mailbox/user) ?
I'm talking about attached doc and excel files.
These seem to be all correctly entered in to the contsupp table in the address1 field,
yet they are not found. Perhaps permissions on the mailbox folders (mailbox/user) ?
Hi again,
OK unless I remember this wrong, your problem is that GoldMine doesnt actually use ADDRESS1+ADDRESS2 to get the file when you try and launch it
The full path is in the LINKEDDOC note field
Which is why you have to use the linkdoc rename tool.
Take a look here
http://www.enigmaware.co.uk/goldmine/tabledefs/contsupp_l.php
Here is an example of a linked document contents in the LINKEDDOC field
~~SYNC=1 ~~CREATETIME=200911101309 ~~FILENAME=D:\GMs\AA\BACKT
OK unless I remember this wrong, your problem is that GoldMine doesnt actually use ADDRESS1+ADDRESS2 to get the file when you try and launch it
The full path is in the LINKEDDOC note field
Which is why you have to use the linkdoc rename tool.
Take a look here
http://www.enigmaware.co.uk/goldmine/tabledefs/contsupp_l.php
Here is an example of a linked document contents in the LINKEDDOC field
~~SYNC=1 ~~CREATETIME=200911101309 ~~FILENAME=D:\GMs\AA\BACKT
I hate to harp, but... anything other than Prior Analytic's Link Mover Tool is like re-creating the wheel. It's a good wheel... use it.
I would agree with stevengraff... the Prior Analytic's tool works well. If you would rather, you can also use GoldBox which can also move the files around if needed. www.redstonesoftbase.com.
If you are doing it with SQL, then GoldMine's log files are probably not getting updated correctly for any sync users (if you use or ever plan to use sync).
If you are doing it with SQL, then GoldMine's log files are probably not getting updated correctly for any sync users (if you use or ever plan to use sync).
ASKER
I got the original database restored,
ran the tool . It claimed to have update several thousand records.
No attachments would show.
I looked at the fields and address1 had been fixed, but not
linkeddoc. I fixed that manually. That was a bit touchy.
A direct replace would not work, but making a temp copy, and a new field with a temp Char() field
did the replace, then the update back to consupp from there worked.
The contsupp records look correct .
So I look at RFC822 and it's not right.
The old paths are still in there.
So, should think the tool failed and I should manually update that too?
ran the tool . It claimed to have update several thousand records.
No attachments would show.
I looked at the fields and address1 had been fixed, but not
linkeddoc. I fixed that manually. That was a bit touchy.
A direct replace would not work, but making a temp copy, and a new field with a temp Char() field
did the replace, then the update back to consupp from there worked.
The contsupp records look correct .
So I look at RFC822 and it's not right.
The old paths are still in there.
So, should think the tool failed and I should manually update that too?
Sorry, now I am stumped. I have never yet had the LinkMover tool fail on me.
Yes, manually update the rfc822 if you can.
Yes, manually update the rfc822 if you can.
hi,
I have had the linkdoc tool fail for me just once. It was on a 64bit windows and SQL2005
The clients main server which had SQL2000 and 32bit windows died and they needed to get up and running quick so restored the SQL backup to the 64bit system
No matter how many times I tried the linkdoc tool whould not alter the NOTES fields (LINKEDDOC)
I eventually had to run it from a windows XP client PC and it worked.
Try running the tool from a client PC
I have had the linkdoc tool fail for me just once. It was on a 64bit windows and SQL2005
The clients main server which had SQL2000 and 32bit windows died and they needed to get up and running quick so restored the SQL backup to the 64bit system
No matter how many times I tried the linkdoc tool whould not alter the NOTES fields (LINKEDDOC)
I eventually had to run it from a windows XP client PC and it worked.
Try running the tool from a client PC
ASKER
I re-ran the tool , this time I had it use Goldmine API instead of SQL.
Happy to report that It worked.
I had some concern that if it first read the now corrected contsupp record it would possibly assume that the related mailbox record was ok too, but it correctly checked and fixed it.
Thanks for your help
Happy to report that It worked.
I had some concern that if it first read the now corrected contsupp record it would possibly assume that the related mailbox record was ok too, but it correctly checked and fixed it.
Thanks for your help
ASKER
Thanks to all. Hopefully this unique goldmine structure is further revealed by this thread for others who are forced to look around behind the curtain.
ASKER
After my change to the contsupp table, it said it found zero records to move or to change the path for.
I admit, I didn't wait out what would have taken hours and instead put in a sql criteria as suggested by their pdf.
INI files all have the correct attachment path and the contsupp table matches.
If you have another diagnosis, I'd like to hear it.
Thanks