I get that, but every single record in the record set has a space before the path begins. The paths are generated using FileListMBS, and there are no spaces in the paths that it’s collecting at that stage. They only appear when I extract them from the database. I just tried [quote] p=f.NativePath.ConvertEncoding(Encodings.UTF8)[/quote]
Inside the FileListMBS loop, where the path is extracted. the result is the same as before - a space before the path upon extraction from the record set, and a failed folderItem.
So the issue seems to be happening within recordset? or with the database?
that one I dont know but I’ve never had such a thing occur
Is there a way in the debugger to browse the contents of an in-memory database? I’d like to see if the space is being added at the db or if it’s something in the recordset created from that db.
no
i’d just connect and make it an on disk one then you can browse that useing lots of tools
switch it back to in memory when you’re happy with things
its a few lines of code to do
Step by step it tests that the folders exist. It wasnt a solution, it was a debugging exercise.
You will feel you have spared yourself the work because someone spotted a space in the path, but I stand by this method of getting a folderitem object.
Building up the file using parent/child relationship is reliable, and avoids all the ‘did you mix : and /’ style questions people have raised above to unpick the path you built up.
It is also not platform-specific, where your built-up path is.
[quote=457510:@Jeff Tullin]Building up the file using parent/child relationship is reliable, and avoids all the ‘did you mix : and /’ style questions people have raised above to unpick the path you built up.
It is also not platform-specific, where your built-up path is.[/quote]
I’m not manipulating the path, in any way that would break it. FileListMBS is getting the nativePath from a folderitem and putting it into the database. That’s then read out of the database and passed to my code as a nativepath. I am adding a delimiter at a certain point, but using a platform-specific test to insert the correct delimiter. That’s the extent of my manipulation of the path.
As for cross-platform compatibility, because I’m using NativePath and native delimiters throughout the whole process it’s inherently cross-platform. The database where these paths are stored is a temporary one - it’s not being shared by multiple applications, it’s in-memory and is destroyed after the work is done.
So if I run this on Windows or Linux, it’s self-contained and won’t pose a problem, because it’s always using nativepath internally.
I’m just trying to avoid 600,000 calls to folderitem on those large 300,000 file folders.
Are you absolutely sure about this? I dont recall Xojo ever automagically changing / to : in file paths when using GetFolderItem and you specify FolderItem.PathTypeNative. Id check to make sure whats being stored & retrieved is correct too.
I am. The result of my FileListMBS pass places the native path into my database: p=f.NativePath …with p being the path
When I test this, it’s the correct native path to the file, no colons, no spaces, nothing weird. The issue is popping up somewhere in either the database or the recordset made from that database. I haven’t had time to test this and may not be able to get to it today, though.
Maybe it’s specific to the older version of Xojo I’m on? I haven’t upgraded yet but plan to move to 2019 soon. - just letting any issues with the latest release shake out first.