D
David-W-Fenton
With Office files, that already exists.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
With Office files, that already exists.
D
David-W-Fenton
bala said "According to them they want to identify the nature of
the file by glancing at the name." A filename of 260+chars is not
glancing, that's reading a sentence per filename. If one wants to
glance, your suggestion of redesigning the naming convention makes
sense. Or store the long stuff to a memo field in a table and copy
to a short name.
I miss being able to vote up an answer when not reading
StackOverflow.com. This would definitely get a +1 vote from me.
S
Salad
Yes. Looking at google it appears one needs to dl a file called DSOFileDavid-W-Fenton said:With Office files, that already exists.
then registering the ActiveX but I saw mention of Office in some
threads. Not having needed such a capability it is nice to know it exists.
T
Tony Toews
What is so long; the filename or the folder name? If folder name, you
can map a drive letter
Set WshNetwork = CreateObject("WScript.Network")
WshNetwork.MapNetworkDrive "L:", "\\mydrive\share"
Then you'd copy the file to drive L:
I doubt very much that you can get around this problem by assiing a
drive letter to a share. I stronglyI suspect in Windows of any sort
the length of the server name, share name, folders and file name is a
maximum of 260.
The drive letter plus the file name is a lot shorter on your system
but the file server won't allow you to use that file name.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
B
bala
I doubt very much that you can get around this problem by assiing a
drive letter to a share. I stronglyI suspect in Windows of any sort
the length of the server name, share name, folders and file name is a
maximum of 260.
The drive letter plus the file name is a lot shorter on your system
but the file server won't allow you to use that file name.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages -http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog -http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated seehttp://www.autofeupdater.com/
I will definitely take a look at the custom file property.
Stuart I definitely will look into it.
Also I did a simple test. I manually renamed an existing Excel file
(contain Data) with a long name (253 char lenght). The long name was
accepted but when I tried to open Excel file it gave me a error that
the file name is too long. When I reverted back to the original short
name or any short name it opened fine and displayed the Data.
Since Windows XP (and I believe Windows 7 too) handles max lenght of
260 I believe even if we successfully rename and copy any files with
long name the behaviour of the copied file can be unpredictable.
Thanks again.
D
David-W-Fenton
Yes. Looking at google it appears one needs to dl a file called
DSOFile
then registering the ActiveX but I saw mention of Office in some
threads. Not having needed such a capability it is nice to know
it exists.
My FileSearch class module already does that. The bizarro thing is
that the DLL doesn't know anything about the Access
meta-properties.
http://dfenton.com/DFA/download/Access/FileSearch.html
D
David-W-Fenton
:
If things are consistent with the past, the 260 limit is on the full
path and filename, not just the filename itself. That would mean
that a 100-character path could not have files with names over 160
in length and still be accessible.
I wonder, though, if that could be gotten round with the File System
Object by loading the list of files into a collection or array. Or,
if the FSO has a collection where you could access the files by
index and then check the name without the path.
Likely not, since to do anything from there the FSO would still have
to use the full path/name, but it's worth a shot.
Since Windows XP (and I believe Windows 7 too) handles max lenght
of 260 I believe even if we successfully rename and copy any files
with long name the behaviour of the copied file can be
unpredictable.
If things are consistent with the past, the 260 limit is on the full
path and filename, not just the filename itself. That would mean
that a 100-character path could not have files with names over 160
in length and still be accessible.
I wonder, though, if that could be gotten round with the File System
Object by loading the list of files into a collection or array. Or,
if the FSO has a collection where you could access the files by
index and then check the name without the path.
Likely not, since to do anything from there the FSO would still have
to use the full path/name, but it's worth a shot.
B
Benny Andersen
I'm pretty certain the Folder Options settings are per user. At a
if my knowledge isn't obsolete, it is saved in seperate streams - a
rare known NTFS feature. When copied to a fat device the properties is
lost. Some file properties, like exif data to jpg is file content.
guess, this information is somewhere in the registry, so you should be
able to control it from code (policy, maybe?). As to individual folders,
the View tab of the Folder Options dialog (Tools | Folder Options from
explorer, also available in Control Panel) has a button to apply the
current view settings to every folder.
if my knowledge isn't obsolete, it is saved in seperate streams - a
rare known NTFS feature. When copied to a fat device the properties is
lost. Some file properties, like exif data to jpg is file content.
J
James A. Fortune
OIC. Well they've still overstepped. IMO they need to see if there's a way
to abbreviate at least part(s) of the name while leaving it still
recognisable. After all, as Salad says, it can hardly be 'glanced' as it
stands.
IC2. IMO, the OS file system names are a poor choice as a database
container, even if WinFS pops up someday with some nice OS database
features. It seems that your customer has taken the concept to its
illogical extreme. Many years ago I had a customer that really wanted
data with "clever" enhancements that would enable him to categorize
the data by sight - obviously something to avoid putting into the
actual data from a database perspective. Yet such idiosyncrasies are
typical of the situations asked for by customers. Ideally, you want
to accommodate the customer's desires without resorting to
questionable database practices. I.e., some ingenuity is in order to
accomplish both. I think your customer has passed the point where
satisfying both goals is possible. From my experience, even when
satisfying both goals is possible, using the OS file names as a pseudo
database leads to inefficiencies that increase dramatically over time.
James A. Fortune
[email protected]
S
Stuart McCall
OIC. Well they've still overstepped. IMO they need to see if there's a way
to abbreviate at least part(s) of the name while leaving it still
recognisable. After all, as Salad says, it can hardly be 'glanced' as it
stands.
IC2. IMO, the OS file system names are a poor choice as a database
container, even if WinFS pops up someday with some nice OS database
features. It seems that your customer has taken the concept to its
illogical extreme. Many years ago I had a customer that really wanted
data with "clever" enhancements that would enable him to categorize
the data by sight - obviously something to avoid putting into the
actual data from a database perspective. Yet such idiosyncrasies are
typical of the situations asked for by customers. Ideally, you want
to accommodate the customer's desires without resorting to
questionable database practices. I.e., some ingenuity is in order to
accomplish both. I think your customer has passed the point where
satisfying both goals is possible. From my experience, even when
satisfying both goals is possible, using the OS file names as a pseudo
database leads to inefficiencies that increase dramatically over time.
James A. Fortune
[email protected]
I know you're not addressing me, but I'd like to say: Well Put.
M
Marshall Barton
James said:IC2. IMO, the OS file system names are a poor choice as a database
container, even if WinFS pops up someday with some nice OS database
features. It seems that your customer has taken the concept to its
illogical extreme. Many years ago I had a customer that really wanted
data with "clever" enhancements that would enable him to categorize
the data by sight - obviously something to avoid putting into the
actual data from a database perspective. Yet such idiosyncrasies are
typical of the situations asked for by customers. Ideally, you want
to accommodate the customer's desires without resorting to
questionable database practices. I.e., some ingenuity is in order to
accomplish both. I think your customer has passed the point where
satisfying both goals is possible. From my experience, even when
satisfying both goals is possible, using the OS file names as a pseudo
database leads to inefficiencies that increase dramatically over time.
Amen.