Has anyone else noticed an issue with base URIs on 2024.2 I can correlate the issue to starting after our upgrade from 2023.2 to 2024.2.
What we are seeing is a truncated Base URI in both companies, but the it’s only giving us the end of it not the start of it. It is also correct in the database, but it is not correct in new attachments or the attachment type screen.
This is what the values show in the database the two are for each company record.
Don’t know don’t use any of them. It seems to work if I don’t give it a UNC path The documents haven’t uploaded either, likely because it’s not a valid path. No errors in the Event Viewer for this issue. I just saw one come through so I can confirm that in the event viewer.
Looks like it’s UNC path breaking it. If I give it a shared drive letter path it’s fine with that. But where it is breaking seems so random. It must be something with the slashes?
Everyone might want to check their attachments, you may not have noticed it because the user attaches something and doesnt try to open their new attachments.
Its related to Ice.Services.BO.DmsStorageTypeRemoveServerPathFromFileStorage
They arbitrarily cut your BaseURI front half off based on the length of your server directory. I.E. if your server directory is "C:\EpicorData\OurData" that length is what is removed from the beginning of your BaseURI. So if your baseURI is “\myserver\myappserver\some\folder\structure” cut the first 22 characters off of that… the length of "C:\EpicorData\OurData"…
Reported in case CS0004680571 issue confirmed by another customer that this is as of 2024.2 and that 2024.1 seems ok.
To Jose and I… this sounds like the work of ChatGPT getting confused about what was actually supposed to be done…
I have also been fighting this in my testing of 2024.1.17 over the last few days. I copy and paste in my URI, save, and close. I open it back up, and I get NTS as the base URI. If it is some shortcut, I have to find out where it might be going. As long as I use a document type when setting the attachment, it goes to the correct place shown in Doc Type Maint.
Scott
Paste your BaseURI in as exactly as you want it. We’ll use "\myserver.domain.local\something\nice" as an example.
If you save the BaseURI and it gets cut off to say "mething\nice" then put this in the field "\myserver.domain.local\so\myserver.domain.local\something\nice"
It should truncate to the actual BaseURI you want. Restart client (it appears that URL may get client cached) and try again.
If the whole thing is disappearing you then have to figure out how much you need to pad in to make it show up. You might have to do something like "\path\path\path\pa\myserver.domain.local\something\nice" to get it to work because your Company Data Directory is longer than your BaseURI.
Also this needs to be done in the browser because it does not validate the client path and the Smart Client does so if you gave the Smart Client "\path\path\path\pa\myserver.domain.local\something\nice" it’s going to say sorry bruh that’s not a valid path.
I must be too tired after this. Terrible time to stop drinking.
I will try in the morning.
I attempted this, but I keep getting an attachment in C:\Epicor\ERP11\LocalClients\Kinetic******************
This C:\ keeps getting pushed in front of what I try to fake it out with.
Scott
Heh that was my first thought when I saw this earlier. Every time I’ve seen this in the wild it’s been the outcome of someone pawing through the URI with character indexes instead of using the URI function or type or object that seems to be baked into everything nowadays. Lose track of which int is which and apply the wrong one, and you get an error matching the length of some other subset of the URI.
Fixed in 2024.2.8 per PRB0283869. Thank’s @pferrington for taking this one on and getting it licked!
We found the attachments that went to “nowhere” they were on the client computers in the client folders because it was using a relative path.
Ran this script in PDQDeploy against all client PCs to generate a report on which clients had the files and then copy pasted them back to our base URI.
UPDATE Ice.XFileRef SET XFileName = CONCAT('\\server.domain.local\company1\Epicor Do', XFileName) WHERE XFileName LIKE 'cuments\%'
UPDATE Ice.XFileRef SET XFileName = CONCAT('\\server2.domain2.local\company2\Epi', XFileName) WHERE XFileName LIKE 'cor Documents\%'
Generated a list of all the attachments attached since we upgraded 11/27
SELECT XFileName FROM Ice.XFileRef WHERE XFileRefNum >= 194910 AND DocTypeID = '' ORDER BY XFileRefNum DESC
Then ran this powershell script against that file to ensure all files existed where they should
# Path to the input TXT file
$InputFile = "C:\TEMP\fileSearch.txt"
# Check if the file exists
if (!(Test-Path -Path $InputFile)) {
Write-Host "Input file not found: $InputFile" -ForegroundColor Red
exit 1
}
# Read all lines from the input file
$filePaths = Get-Content -Path $InputFile
# Initialize an array for missing files
$missingFiles = @()
# Loop through each file path
foreach ($filePath in $filePaths) {
if (!(Test-Path -Path $filePath)) {
# Add missing file path to the array
$missingFiles += $filePath
}
}
# Output missing files
if ($missingFiles.Count -eq 0) {
Write-Host "All files exist." -ForegroundColor Green
} else {
Write-Host "The following files are missing:" -ForegroundColor Yellow
$missingFiles | ForEach-Object { Write-Host $_ -ForegroundColor Red }
}
