06-28-2011 05:44 PM
I made this account just to ask this question and I'd really appreciate any info or ideas.
A friend of mine who's a great IT guy, but has no programming background, is in a funky situation. He asked for my help because I've been developing msft solutions since the 90s but after helping him troubleshoot this (off and on) for days we have not had success. We help our friends when we can.
His client has a small website that currently connects to an act database that was used for development purposes and now he is being asked to make it point to the production Act! db. For reasons that I don't know the original developer of the website has dropped off the grid.
I don't have access to the development environment or the source code.
Steps that have been taken:
I asked him to give me the portion of web.config that has the act connection string. It looks something like this:
<add key="ACT_pad_file" value="\\someserver\directory1\directory2\longassdirectorystructure\somefilename.pad" />
The web application works properly (returns data when searched) with this setting.
I recommended that he stop IIS, rename the working file to "somefilename_old.pad", copy and paste the production Act! .pad file into the same directory as the working one, and rename it to what the original file was named, "somefilename.pad".
The web application finds no records when testing it with the same search criteria.
My debugging brain kicks in and I suggest a few things to him. Please let me know if I've overlooked something or if I'm doing something wrong based on my lack of Act! understanding.
1. From there I had him paste the new fully qualfied path that is in the web config into the Run bar on the web server to ensure that the web-server can see the file. It did see it and tried to open the file.
2. Next I asked him to open the .pad file in Act! to verify that this new database file actually has the data within it that correlates with the search criteria. I imagine that row could have been dropped in the new one - the connection could work, but the record is not there. We currently can not verify this because apparently the web-server had a trial version of Act! that has now expired.
2.a. He then had another third (fourth?) party (Act! consultant) open the new production Act! database and confirmed that the data we were searching for existed in the database.
3. I suggested - in my ignorance of how Act! handles permissions that perhaps this second, new Act! database needs an administrator to go into the Act! db and switch some settings on that allow for external processes to connect. This is untested still. I have no idea if it's even a legitimate path to go down.
4. This is ugly but I also had the thought that the original web developer may have hard coded something into the .Net code that would prevent the website to read from a different database than the one used in development to ensure that the end client had to return to him in order to point to the production db. I hope this isn't the case but you can never leave a stone unturned.
5. One test that I think would be a potential next step would be to make a backup of the development .pad file, then open the original, drop all rows/tables, and import the production data. I know how I'd do this with a database I'm familiar with but I don't know Act! at all.
6. This kinda piggy backs on 4. but I suggested that just because there is a value in the config file pointing to a db that the compiled code could be using a system odbc connection, and not the value in config at all. He checked the web-server and let me know that there weren't any suspicious odbc connections, but I haven't seen it. I don't trust hearsay when debugging.
7. I hope that I'm critically over-thinking this process and someone here has a more elegant direction for me to look in.
My life doesn't change in any important way one iota if this is resolved or not, but I'd really like to help out a buddy I've known for 10+ years. Any suggestions are very welcome.
Thanks in advance.
06-29-2011 06:09 AM
There are some more knowledgeable people than me when it comes to ACT!, but I'll toss out what I know, to hopefully help get you in the right direction.
First, the .pad file is more like a config/manifest file itself. It's just XML (this is what my test one looks like).
<?xml version="1.0" standalone="no"?> <!DOCTYPE ACTDatabasePADFile> <!--This file represents a Pointer to an Act Database or [PAD]--> <ACTDatabase name="ProposalPushTest" host="IS2" location="F:\Act Test DB" type="Sql" />
The file that contains the actual data is the ".adf", and the log file is the ".alf". These file extensions are similar to the setup of MS SQL Server, which ACT! is based on.
I would think, ideally, that you use the existing database, and just import the production information into it. Or you create a new one from scratch, then import the existing production information into it. This way all of the ACT! references would be setup properly. Otherwise, I think you'll just have to manually edit the .pad file, which is not always a good thing when messing with the manifest file of a program that you are unfamiliar with.
I know you can export a lot of information from ACT! into .xls files, and import those into another database. In my company, a non-technical person is our ACT! "admin", and she has no problems with this. Hopefully others will be able to build off of this and give you more specific direction.
06-29-2011 10:26 AM
The first question that comes to mind after reading this is in regards to how the database was to moved. Was the database simply copied/pasted to the location? If so, this Knowledge Base outlines the steps required to move an Act database, it may be possible that the database is moved, but not attached to SQL.
To rename a database, the best procedure is to create a backup and restore it, I wasn't exactly clear if this had occurred, but it seemed to be based on what was written.
Additionally, and this is probably something your already aware of, but I prefer to test my connection via a UDL file, I simply rename a text file with the extension UDL, save and reopen, this way I can verify connectivity, I was unsure if this had been tested or not, I saw that data was not being returned from the query, but wasn't sure if this was as a result of the connection failing or something else.
There are no settings in Act that needs to be set to allow access from third party applications, so long as the ODBC or the OLEDB connection is successful the data should be able to be queried.
Hopefully some of this helps to steer you in the right direction, if you have any follow up questions don't hesitate to ask.