I think you're missing the trailing backslash.
I.E. '\\Server\share\'
The below code shows pulling the UNC Path from an attribute table.
The table values are Code: TestFileLoc, Description:'\\server\share\
The code doesn't work if the trailing backslash is missing.
FileTbl.RESET;
FileTbl.SETRANGE(Path,FileLoc.Description);
FileTbl.SETRANGE("Is a file",TRUE);
IF FileTbl.FINDFIRST THEN
MESSAGE('The First File is %1',FileTbl.Path+FileTbl.Name);
Please post back if you find any solutions to this.
In the Norwegian Remittance (Electronic Payments) granule, Microsoft uses the table File record to search for bank files and when setting up with UNC path in RTC no files are listed. In Classic Client it works. We made sure that the domain user running the Nav Server service has proper rights on the folder as well as the domain user running the RTC.
I find it as a poor solution to mount the disk where the Dynamics Nav Server is running, or is this really what they thought should be done?
I think this is the most likely place to start looking. the most likely issue is that the Middle tier is started with different permissions than the user, so in the Form you are accessing the UNC as the logged in user, and through code its the user that starts the service.
I continued down the permission path to see if it could help, but..
First i tried this:
I gave the share "Everyone" Full Control. - No Success.
I Tried setting the "Anonymous Logon" Full Control - No Success
I've now removed the everyone and anonymous logon.
When looking into the Event Viewer on the server where the share exists under "Security". My user "dev\bruker1" running the RTC client is the one trying to logon to the share according to this, and "dev\bruker1" has "Full Control" on the share so it seems to be OK but no files are shown?
This event is generated when a logon session is created. It is generated on the computer that was accessed.
The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).
The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.
The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
In our case the only solution was to avoid the file table :roll:. We rewrote the whole code part and use Windows Script Control and File System Object Automation servers now instead to import multiple files from a directory.
In my company we have the same problem and made a support case with Microsoft.
MS Premier Support confirmed that there is a bug in the original 2009 SP1 release which prevents the NST from accessing files on a network share in some cases.
In order to work you MUST set up delegation correctly, but even then it may not work.
Right now we are testing a hotfix from MS to see if it works with the hotfix.
If you are having the same problem I suggest you contact MS support to get a hotfix.
Do you have any KB Article number for this issue or hotfix I can refer to when contacting Micrsoft?
I'm trying with 2009 SP1 build 30863 right now - or rather I hope I can get to try it, I'm dealing with a lot of internal bureaucracy in the IT department ](*,)
From the hotfix.txt:
This release contains fixes for the following bug and KB Article numbers :
======================
57967 982464
57744 982465
57711 982154
57650 981606
57647 981605
In our case the only solution was to avoid the file table :roll:. We rewrote the whole code part and use Windows Script Control and File System Object Automation servers now instead to import multiple files from a directory.
The code snippet for this can now be found in the post by Walter Albiker in this thread on msdynamics.de
We have setup a proper 3 tier, and it seems that when a user logs into the RTC and runs the remittance import they get this message.
which says that 0 files are found. The number of files that are in the directory it tries to read is 1.
The funny thing is that when i browse to the directory using the '...' and click either cancel or ok in the dialog i get this message.
which says that there is 1 file found.
Everyone is allowed to read this folder. I have also set that the dynamics service and the user im logged in on has all rights.
Comments
I.E. '\\Server\share\'
The below code shows pulling the UNC Path from an attribute table.
The table values are Code: TestFileLoc, Description:'\\server\share\
The code doesn't work if the trailing backslash is missing.
Hope this helps
NAVDabbler
In the Norwegian Remittance (Electronic Payments) granule, Microsoft uses the table File record to search for bank files and when setting up with UNC path in RTC no files are listed. In Classic Client it works. We made sure that the domain user running the Nav Server service has proper rights on the folder as well as the domain user running the RTC.
I find it as a poor solution to mount the disk where the Dynamics Nav Server is running, or is this really what they thought should be done?
:thumbsup:
I think this is the most likely place to start looking. the most likely issue is that the Middle tier is started with different permissions than the user, so in the Form you are accessing the UNC as the logged in user, and through code its the user that starts the service.
First i tried this:
I gave the share "Everyone" Full Control. - No Success.
I Tried setting the "Anonymous Logon" Full Control - No Success
I've now removed the everyone and anonymous logon.
When looking into the Event Viewer on the server where the share exists under "Security". My user "dev\bruker1" running the RTC client is the one trying to logon to the share according to this, and "dev\bruker1" has "Full Control" on the share so it seems to be OK but no files are shown?
An account was successfully logged on.
Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0
Logon Type: 3
New Logon:
Security ID: DEV\bruker1
Account Name: bruker1
Account Domain: DEV
Logon ID: 0x7bbf73e
Logon GUID: {98bac523-c276-065e-0747-e78e2d4b5102}
Process Information:
Process ID: 0x0
Process Name: -
Network Information:
Workstation Name:
Source Network Address: 10.100.10.100
Source Port: 55928
Detailed Authentication Information:
Logon Process: Kerberos
Authentication Package: Kerberos
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon session is created. It is generated on the computer that was accessed.
The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).
The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.
The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
MS Premier Support confirmed that there is a bug in the original 2009 SP1 release which prevents the NST from accessing files on a network share in some cases.
In order to work you MUST set up delegation correctly, but even then it may not work.
Right now we are testing a hotfix from MS to see if it works with the hotfix.
If you are having the same problem I suggest you contact MS support to get a hotfix.
I'm trying with 2009 SP1 build 30863 right now - or rather I hope I can get to try it, I'm dealing with a lot of internal bureaucracy in the IT department ](*,)
From the hotfix.txt:
This release contains fixes for the following bug and KB Article numbers :
======================
57967 982464
57744 982465
57711 982154
57650 981606
57647 981605
I would like to bumb this post.
We have setup a proper 3 tier, and it seems that when a user logs into the RTC and runs the remittance import they get this message.
which says that 0 files are found. The number of files that are in the directory it tries to read is 1.
The funny thing is that when i browse to the directory using the '...' and click either cancel or ok in the dialog i get this message.
which says that there is 1 file found.
Everyone is allowed to read this folder. I have also set that the dynamics service and the user im logged in on has all rights.
Has anyone found a solution?
PS. Running nav 2009 R2
http://blogs.msdn.com/b/nav/archive/201 ... 09-r2.aspx