Any help will be greatly appreciated.

Uzi

• Make sure all of your users are on version 5.2. If you still have users on version 5.0 or below, they will update the old index and users on 5.2 won't be able to see their files (and vice versa).
• Make sure you are calling the correct version of import.exe. (Version 1.0.1970.27760) I believe this is the same version as with 5.1 but haven't checked.
• Make sure you have all the import.exe dependencies in the path from which you are invoking import.exe. (see below)
• Include full path names in the command line arguments so import.exe doesn't get confused. (Don't include a full path in the /F: parameter argument, just a file name without extension.)
• It's safest to invoke import.exe from the winpoint directory (where all the dependencies are).
• Make sure your windows\winpoint.ini has the correct folder paths. Also, if you're running under a system with multiple users, make sure the {drv}:\Documents and Settings\{username}\Windows\winpoint.ini file is set up properly.
• Invoke import.exe from a system that has Point installed on it and from a user that has Point installed.
• Make sure the user that is running import.exe has full permissions. (Probably not your problem since the file is being written.)
• Make sure that the import.exe managed code has proper permissions. (A .Net thing.) See article x.
• Check your return codes if you're running from a scripting or other language.

Here are the dependencies for import.exe (someone please correct me if I'm missing anything):

• pdd.dll
• AesLib.dll
• Sqlite.dll
• sbautils.dll
• sbaparam.dll
• mfc71.dll
• msvcp71.dll
• msvcr71.dll
• Implode.dll

I hope this is helpful. If you find a solution, I'm sure that everyone on this board would love to hear about it.

- Mike
mike@mtig.biz

Thanks for the extensive checklist. Everything seems OK.

We are invoking c:\point\import.exe via a batch file executed on a WinNT server where Point 5.2 is installed, including the last version of import.exe file (1.0.1970.27760), which has all the permissions for "everybody", and all the file dependencies. Everything else seems OK.

In fact, import.exe seems to work OK, and creates the appropriate .PRS file in the Prospect directory. The only problem is that the prospect.index file is NOT updated (it's time stamp is unchanged), and the new Prospect is not visible to a "Search". Invoking "File --> Rebuild List" from within Point, solves the problem.

It seems to me that the only problem is that under Point 5.2, import.exe doesn't update the index. I wonder if anybody else is seeing this problem.

I've sent several emails about this problem to support@calyxsoftware.com, without getting ANY response. The support phone line is busy every time I call, and the "Live Help", after trying for about 5 minutes, always tells me that "No support person is available at this time, please try later". Is Calyx Software's grip on the industry so tight that they can afford such indifference to their users' pleas for help?

Uzi
 

I'm sorry for the inconvenience. Calyx recently upgraded the phone system, and is in the process of adding more lines to meet the increased customer demand for the 5.2 upgrade.  Having said that, support for import.exe is actually available from Calyx development personnel, not the regular tech support line.  If you have the Preferred Point Partner integration guide you should already have a direct contact listed in the guide.

Anyway, let's troubleshoot the problem:

1) Do you have a userprofile.ini in the c:\winpoint\user folder. 
2) What are the directories listed in the [Directories] section?
3) Do these directories match the ones listed in the [Directories] section in winpoint.ini found under \winnt directory?
4) For the data folder where the PRS file is being created, please locate the Folder.ini file, and open it. What does it show for IndexVersion=? 
5) Does the data folder reside on a network drive or local?

 

Bryan
Point Product Manager

Thanks for the quick response. I appreciate you taking this on!

1) Do you have a userprofile.ini in the c:\winpoint\user folder.
- yes

2) What are the directories listed in the [Directories] section?

[Directories]
Folder0=P:\PNTDATA
Folder1=P:\CLOSED
Folder2=P:\SUSPENDED
Folder3=SENTINEL

Note: P is the logical name of a network drive (actually drive E).

3) Do these directories match the ones listed in the [Directories]
section in winpoint.ini found under \winnt directory?
- Yes

4) For the data folder where the PRS file is being created, please
locate the Folder.ini file, and open it. What does it show for
IndexVersion=?

[Folder]
Name=Primary Data Folder
Available=1
IndexVersion=2

5) Does the data folder reside on a network drive or local?

- It's on drive E: of the server, which is also defined as network drive P:

Thanks again. I'm looking forward to a quick resolution.

Uzi

I have also found it beneficial to not use the autonaming. I always specify a file name in my import.exe arguments (the /F: argument).

Another culprit that keeps cropping up for me is the import file. There are so many things to remember when calling import.exe that it's easy to lose that little issue and spend hours trying to resolve something else. I build the import file on the fly within my program so that I have to pay attention to it; otherwise, I will invariably spend hours on something that isn't really the issue.

Just double-check your import settings and make sure all the fields match up, that you have a consistent delimiter, and that the file is not set up for updating an existing file. Also, double check your headers to make sure they match exactly. Any little thing like this can cause a problem.

Check your import.exe exit codes. That may give you a clue as to what's going on. I can't provide a list of exit codes but maybe Brian can.

- Mike
mike@mtig.biz

1) Can you try running import with a local data folder? Create a local folder (e.g. c:\pntdatatest) on the machine you're running import, and try calling import on that folder.
2) Can you try running import on another machine in the office, preferably not a server rather a machine that uses Point a lot.

Please post your results.

What OS are you are running on the machine where it's not working?

Thanks 

Bryan
Point Product Manager

Thanks for the additional info.

The import file seems OK (there's no problem after I re-build the index).

How do I check the import.exe exit codes if it's invoked by a BAT file?

How do you tell import.exe that you are updating an existing file? Or does it find out by itself based on the SSN?

Where do you find info on import.exe? I couldn't find any in the Point Help.

Thanks again,

Uzi

I do all my testing on a Windows 2000 machine. I currently don't have access to any other machine in the office (it's a holiday...). Point is installed on drive C, and the Point data folders are on drive E (which is also known as network drive P). I run import.exe via a BAT file. We use "autonaming" of files.

Here are my test results:

c:\winpoint\import.exe "e:\in\2123J.txt" "e:\in\mprf.imp" "e:\point\pntdata\prospect"

The above BAT file is the only one that successfully creates a new Prospect file.

The following BAT files did NOT create a new Prospect file:

c:\winpoint\import.exe "e:\in\2123J.txt" "e:\in\mprf.imp" "p:\point\pntdata\prospect"

c:\winpoint\import.exe "e:\in\2123J.txt" "e:\in\mprf.imp" "c:\temp"

Does import.exe produces a "log" that might show us success or error conditions? This would be extremely useful.

Thanks, Uzi