ftp from Access: problems

[DFS]

From an Access 2003 module: v = Shell("ftp.exe -s:D:\ftpCommands.txt")

Contents of D:\ftpCommands.txt
----------------------------------
open ftp.destination.com
user password
send sourceFile destFile
bye
Results:
ftp> |o
invalid command
Any ideas?

[Terry Kreft]

Send?

You're looking for Put

If you open a command window, start ftp and then enter ? at the ftp> prompt
it will list the valid ftp commands.
--
Terry Kreft

"DFS" <nospam@dfs_.com> wrote in message
news:S1******************@fe04.lga...

From an Access 2003 module: v = Shell("ftp.exe -s:D:\ftpCommands.txt")

Contents of D:\ftpCommands.txt
----------------------------------
open ftp.destination.com
user password
send sourceFile destFile
bye
Results:
ftp> |o
invalid command
Any ideas?

[Danny J. Lesandrini]

I suppose I should examine your script to find the error, but you could just
download my working FTP tool. It displays the FTP commands used to
download, upload, delete and get directory list ... and it works.

http://www.databasejournal.com/featu...le.php/3513061

--

Danny J. Lesandrini
dl*********@hotmail.com
http://amazecreations.com/datafast
"DFS" <nospam@dfs_.com> wrote ...

From an Access 2003 module: v = Shell("ftp.exe -s:D:\ftpCommands.txt")

Contents of D:\ftpCommands.txt
----------------------------------
open ftp.destination.com
user password
send sourceFile destFile
bye
Results:
ftp> |o
invalid command
Any ideas?

[DFS]

Terry Kreft wrote:

Send?

You're looking for Put

If you open a command window, start ftp and then enter ? at the ftp>
prompt it will list the valid ftp commands.
Send works fine. But the script never gets there.
ftp -s:D:\ftpCommands.txt ftp.destination.com

And it connects just fine, but errors out on the login.


"DFS" <nospam@dfs_.com> wrote in message
news:S1******************@fe04.lga...

From an Access 2003 module: v = Shell("ftp.exe
-s:D:\ftpCommands.txt")

Contents of D:\ftpCommands.txt
----------------------------------
open ftp.destination.com
user password
send sourceFile destFile
bye
Results:
ftp> |o
invalid command
Any ideas?

[Danny J. Lesandrini]

Ok, I opened my FTP Demo tool and found the syntax.

sExe = Environ$("COMSPEC")
sExe = Left$(sExe, Len(sExe) - Len(Dir(sExe)))
sExe = sExe & "ftp.exe -s:" & q & sScrFile & q

ShellWait sExe, vbHide

The end result of sExe is this ...
C:\WINDOWS\system32\ftp.exe -s:"C:\DBJ\Download.src"

This script works ...

open ftp.amazecreations.com
DBJUser
start123
cd DBJ
binary
lcd "C:\Desktop\DBJ"
get "text.txt" "C:\DBJ\test.txt"
bye

or this

open ftp.amazecreations.com
DBJUser
start123
cd DBJ
binary
lcd "C:\DBJ"
put "C:\DBJ\JustForKicks.txt"
bye

--

Danny J. Lesandrini
dl*********@hotmail.com
http://amazecreations.com/datafast

Send works fine. But the script never gets there.
ftp -s:D:\ftpCommands.txt ftp.destination.com

And it connects just fine, but errors out on the login.

[DFS]

Danny J. Lesandrini wrote:

Ok, I opened my FTP Demo tool and found the syntax.

sExe = Environ$("COMSPEC")
sExe = Left$(sExe, Len(sExe) - Len(Dir(sExe)))
sExe = sExe & "ftp.exe -s:" & q & sScrFile & q
The Environ$ setting is the key. Using it and regular old Shell, I got my
script to work.

Dim sExe As String
sExe = Environ$("COMSPEC")
sExe = Left$(sExe, Len(sExe) - Len(dir(sExe)))
sExe = sExe & "ftp -s:D:\upload.txt"
Shell sExe
(note you don't have to use a .scr file. A .txt file will work).

I like your ftp demo system, by the way, and I'm going to adapt parts of it
for use at my client site (mainly to check the nightly file upload). If
that's OK with you.

Thanks for your help.


ShellWait sExe, vbHide

The end result of sExe is this ...
C:\WINDOWS\system32\ftp.exe -s:"C:\DBJ\Download.src"

This script works ...

open ftp.amazecreations.com
DBJUser
start123
cd DBJ
binary
lcd "C:\Desktop\DBJ"
get "text.txt" "C:\DBJ\test.txt"
bye

or this

open ftp.amazecreations.com
DBJUser
start123
cd DBJ
binary
lcd "C:\DBJ"
put "C:\DBJ\JustForKicks.txt"
bye

Send works fine. But the script never gets there.
ftp -s:D:\ftpCommands.txt ftp.destination.com

And it connects just fine, but errors out on the login.

[DFS]

And you don't even have to go through the trouble of using Environ$ unless
Windows was installed differently than normal

Shell "C:\WINDOWS\System32\ftp -s:D:\upload.txt"

works fine.

DFS wrote:

Danny J. Lesandrini wrote:

Ok, I opened my FTP Demo tool and found the syntax.

sExe = Environ$("COMSPEC")
sExe = Left$(sExe, Len(sExe) - Len(Dir(sExe)))
sExe = sExe & "ftp.exe -s:" & q & sScrFile & q

The Environ$ setting is the key. Using it and regular old Shell, I
got my script to work.

Dim sExe As String
sExe = Environ$("COMSPEC")
sExe = Left$(sExe, Len(sExe) - Len(dir(sExe)))
sExe = sExe & "ftp -s:D:\upload.txt"
Shell sExe
(note you don't have to use a .scr file. A .txt file will work).

I like your ftp demo system, by the way, and I'm going to adapt parts
of it for use at my client site (mainly to check the nightly file
upload). If that's OK with you.

Thanks for your help.

ShellWait sExe, vbHide

The end result of sExe is this ...
C:\WINDOWS\system32\ftp.exe -s:"C:\DBJ\Download.src"

This script works ...

open ftp.amazecreations.com
DBJUser
start123
cd DBJ
binary
lcd "C:\Desktop\DBJ"
get "text.txt" "C:\DBJ\test.txt"
bye

or this

open ftp.amazecreations.com
DBJUser
start123
cd DBJ
binary
lcd "C:\DBJ"
put "C:\DBJ\JustForKicks.txt"
bye

Send works fine. But the script never gets there.
ftp -s:D:\ftpCommands.txt ftp.destination.com

And it connects just fine, but errors out on the login.

[Terry Kreft]

Nope that''s bad advice there are a whole host of systems I've seen where
windows is installed in the folder WinNT rather than Windows.

It's poor practice to hard code variables when there is a way to getthe
value dynamically anyway.
--
Terry Kreft

"DFS" <nospam@dfs_.com> wrote in message news:9n****************@fe02.lga...

And you don't even have to go through the trouble of using Environ$ unless
Windows was installed differently than normal

Shell "C:\WINDOWS\System32\ftp -s:D:\upload.txt"

works fine.

DFS wrote:

Danny J. Lesandrini wrote:

Ok, I opened my FTP Demo tool and found the syntax.

sExe = Environ$("COMSPEC")
sExe = Left$(sExe, Len(sExe) - Len(Dir(sExe)))
sExe = sExe & "ftp.exe -s:" & q & sScrFile & q

The Environ$ setting is the key. Using it and regular old Shell, I
got my script to work.

Dim sExe As String
sExe = Environ$("COMSPEC")
sExe = Left$(sExe, Len(sExe) - Len(dir(sExe)))
sExe = sExe & "ftp -s:D:\upload.txt"
Shell sExe
(note you don't have to use a .scr file. A .txt file will work).

I like your ftp demo system, by the way, and I'm going to adapt parts
of it for use at my client site (mainly to check the nightly file
upload). If that's OK with you.

Thanks for your help.

ShellWait sExe, vbHide

The end result of sExe is this ...
C:\WINDOWS\system32\ftp.exe -s:"C:\DBJ\Download.src"

This script works ...

open ftp.amazecreations.com
DBJUser
start123
cd DBJ
binary
lcd "C:\Desktop\DBJ"
get "text.txt" "C:\DBJ\test.txt"
bye

or this

open ftp.amazecreations.com
DBJUser
start123
cd DBJ
binary
lcd "C:\DBJ"
put "C:\DBJ\JustForKicks.txt"
bye

Send works fine. But the script never gets there.
ftp -s:D:\ftpCommands.txt ftp.destination.com

And it connects just fine, but errors out on the login.

[Terry Kreft]

Whoops, apologies, if I had taken my own advice and read the return from
?properly I would have seen it listed.

I always use Put hence my incorrect post.

--
Terry Kreft

"DFS" <nospam@dfs_.com> wrote in message
news:kb******************@fe04.lga...

Terry Kreft wrote:

Send?

You're looking for Put

If you open a command window, start ftp and then enter ? at the ftp>
prompt it will list the valid ftp commands.

Send works fine. But the script never gets there.
ftp -s:D:\ftpCommands.txt ftp.destination.com

And it connects just fine, but errors out on the login.

"DFS" <nospam@dfs_.com> wrote in message
news:S1******************@fe04.lga...

From an Access 2003 module: v = Shell("ftp.exe
-s:D:\ftpCommands.txt")

Contents of D:\ftpCommands.txt
----------------------------------
open ftp.destination.com
user password
send sourceFile destFile
bye
Results:
ftp> |o
invalid command
Any ideas?

[Tom van Stiphout]

On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
<te*********@mps.co.uk> wrote:

But it's somewhat reasonable to assume ftp.exe is installed in the
system32 folder, which by default is in the path. Actually the use of
ComSpec assumes that as well. So one might write:
Shell "ftp.exe -s:D:\upload.txt"

-Tom.

Nope that''s bad advice there are a whole host of systems I've seen where
windows is installed in the folder WinNT rather than Windows.

It's poor practice to hard code variables when there is a way to getthe
value dynamically anyway.

[Terry Kreft]

System32 is in the path on the majority of machines but I have come across a
significant number of machines where it is not.

--
Terry Kreft

"Tom van Stiphout" <no*************@cox.net> wrote in message
news:fp********************************@4ax.com...

On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
<te*********@mps.co.uk> wrote:

But it's somewhat reasonable to assume ftp.exe is installed in the
system32 folder, which by default is in the path. Actually the use of
ComSpec assumes that as well. So one might write:
Shell "ftp.exe -s:D:\upload.txt"

-Tom.

Nope that''s bad advice there are a whole host of systems I've seen where
windows is installed in the folder WinNT rather than Windows.

It's poor practice to hard code variables when there is a way to getthe
value dynamically anyway.

[DFS]

Tom van Stiphout wrote:

On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
<te*********@mps.co.uk> wrote:

But it's somewhat reasonable to assume ftp.exe is installed in the
system32 folder, which by default is in the path. Actually the use of
ComSpec assumes that as well. So one might write:
Shell "ftp.exe -s:D:\upload.txt"

That doesn't work - at least on my WinServer system. That's what prompted
my initial post.

I had to specify C:\Windows\System32\ftp, and it runs fine.

-Tom.

Nope that''s bad advice there are a whole host of systems I've seen
where windows is installed in the folder WinNT rather than Windows.
Hmmm... sounds ancient.
It's poor practice to hard code variables when there is a way to
getthe value dynamically anyway.

Probably, but the client machine uses C:\Windows\System32. So does 100% of
standard XP and Server 2003 installs.

[Terry Kreft]

In the business world operating systems do not tend to get upgraded until
the decision to do so is forced.

I spend a lot of time considering how to make my code generic and flexible
simply because there are a lot of systems out there which are not standard
installs, also there is nothing more likely to generate contempt from
professional developers than to find a system with hardcoded paths in it.

If you want to create inflexible code then that's entirely up to you, but
please don't pretend that there is any value to doing this except that it
allows you to be lazy.

--
Terry Kreft

"DFS" <nospam@dfs_.com> wrote in message
news:C9*****************@fe03.lga...

Tom van Stiphout wrote:

On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
<te*********@mps.co.uk> wrote:

But it's somewhat reasonable to assume ftp.exe is installed in the
system32 folder, which by default is in the path. Actually the use of
ComSpec assumes that as well. So one might write:
Shell "ftp.exe -s:D:\upload.txt"

That doesn't work - at least on my WinServer system. That's what prompted
my initial post.

I had to specify C:\Windows\System32\ftp, and it runs fine.

-Tom.

Nope that''s bad advice there are a whole host of systems I've seen
where windows is installed in the folder WinNT rather than Windows.
Hmmm... sounds ancient.
It's poor practice to hard code variables when there is a way to
getthe value dynamically anyway.

Probably, but the client machine uses C:\Windows\System32. So does 100%
of
standard XP and Server 2003 installs.

[Lyle Fairfield]

My idea is that I have written a really gnarly miserable class for FTP
which doesn't care where the FTP.exe file is.
BUT
I don't use it any more, because ADO gives me a simpler way to upload a
file and this simpler file uses a technology that is already there in
Access >= 2000.

Public Sub UploadFile( _
ByVal FromPath As String, _
ByVal ToFile As String, _
ByVal Server As String, _
Optional ByVal UserName As String, _
Optional ByVal Password As String)

Dim r As ADODB.Record
Dim s As ADODB.Stream
Set r = New ADODB.Record
Set s = New ADODB.Stream

r.Open Server & "/" & ToFile, , adModeWrite, adCreateOverwrite, ,
UserName, Password

With s
.Open r, , adOpenStreamFromRecord
.Type = adTypeBinary
.LoadFromFile FromPath
.Close
End With

r.Close

End Sub

In Windows XP if you don't send the UserName and Password you will be
prompted for same.

[DFS]

Terry Kreft wrote:

In the business world operating systems do not tend to get upgraded
until the decision to do so is forced.
You have clients still running NT on the desktop?

I spend a lot of time considering how to make my code generic and
flexible simply because there are a lot of systems out there which
are not standard installs, also there is nothing more likely to
generate contempt from professional developers than to find a system
with hardcoded paths in it.

If you want to create inflexible code then that's entirely up to you,
but please don't pretend that there is any value to doing this except
that it allows you to be lazy.
If you're telling me you have no hard-coded paths in any of your code, I'd
say... you're a liar.

Get over yourself.


"DFS" <nospam@dfs_.com> wrote in message
news:C9*****************@fe03.lga...

Tom van Stiphout wrote:

On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
<te*********@mps.co.uk> wrote:

But it's somewhat reasonable to assume ftp.exe is installed in the
system32 folder, which by default is in the path. Actually the use
of ComSpec assumes that as well. So one might write:
Shell "ftp.exe -s:D:\upload.txt"

That doesn't work - at least on my WinServer system. That's what
prompted my initial post.

I had to specify C:\Windows\System32\ftp, and it runs fine.

-Tom.
Nope that''s bad advice there are a whole host of systems I've seen
where windows is installed in the folder WinNT rather than Windows.

Hmmm... sounds ancient.

It's poor practice to hard code variables when there is a way to
getthe value dynamically anyway.

Probably, but the client machine uses C:\Windows\System32. So does
100% of
standard XP and Server 2003 installs.

[DFS]

And on the line beginning with r.Open Server, that code throws

"Error -2147217895 (80040e19)
Object or data matching the name, range, or selection criteria was not found
within the scope of this operation"

with this version (which compiles):

Dim Server As String, ToFile As String, FromPath As String
Dim r As ADODB.Record
Dim s As ADODB.Stream
Set r = New ADODB.Record
Set s = New ADODB.Stream

Server = "ftp.destination.com"
(I also tried ftp://ftp.destination.com)

ToFile = "Uploads/DFS_test4.html"

r.Open Server & "/" & ToFile, , adModeWrite, adCreateOverwrite, ,
"user", "password"

With s
.Open r, , adOpenStreamFromRecord
.Type = adTypeBinary
.LoadFromFile "D:\DFS.html"
.Close
End With

r.Close

Lyle Fairfield wrote:

My idea is that I have written a really gnarly miserable class for FTP
which doesn't care where the FTP.exe file is.
BUT
I don't use it any more, because ADO gives me a simpler way to upload
a file and this simpler file uses a technology that is already there
in Access >= 2000.

Public Sub UploadFile( _
ByVal FromPath As String, _
ByVal ToFile As String, _
ByVal Server As String, _
Optional ByVal UserName As String, _
Optional ByVal Password As String)

Dim r As ADODB.Record
Dim s As ADODB.Stream
Set r = New ADODB.Record
Set s = New ADODB.Stream

r.Open Server & "/" & ToFile, , adModeWrite, adCreateOverwrite, ,
UserName, Password

With s
.Open r, , adOpenStreamFromRecord
.Type = adTypeBinary
.LoadFromFile FromPath
.Close
End With

r.Close

End Sub

In Windows XP if you don't send the UserName and Password you will be
prompted for same.

[Lyle Fairfield]

I will just say I try not to use hard coded paths in production code.

In utilities that a developer might run from the VBE window I use hard
coded paths frequently, but I try to put the path at the top in a Const
so that it can be found and changed easily. But this is not production
code.

I find that trying very hard to use just Access, VBA, ADO, DAO and
various API functions in production code makes this whole question more
or less redundant.

Now when I say I try, of course, you could find hard coded paths in my
code. (e.g send e-mail with OE). It's because sometimes I'm in a hurry,
sometimes I'm careless and sometimes I've written something as an
example, which other have decided to use in production code,
(arghhhhhhh), like the OE send mail thing.

Does this mean that I am a liar?

I hope not. I hope it just reflects something like Joe Friday's quote:
(probably munged) "We recruit form the human race".

[Lyle Fairfield]

Probably it was "We recruit FROM the human race".

[Rick Brandt]

DFS wrote:

Terry Kreft wrote:

In the business world operating systems do not tend to get upgraded
until the decision to do so is forced.

You have clients still running NT on the desktop?

If NT is upgraded to 2000 or XP then the "Windows" folder will still be WinNT.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

[Terry Kreft]

I have clients using Win98 and I cerainly have clients using WinNT.

Hard coding paths
Never in production work, concept and testing maybe it depends on how
trivial it is.

Accusing me of lying though, pretty much sums up your attitude doesn't it,
you obviously can't even deal with the concept that there are some people
who try to do their job properly and professionally rather than cludge it
like the amateur you appear to be.

Oh, and if "getting over myself" involves falling to your standards I think
I'll pass.

--
Terry Kreft

"DFS" <nospam@dfs_.com> wrote in message
news:tL*******************@fe04.lga...

Terry Kreft wrote:

In the business world operating systems do not tend to get upgraded
until the decision to do so is forced.

You have clients still running NT on the desktop?

I spend a lot of time considering how to make my code generic and
flexible simply because there are a lot of systems out there which
are not standard installs, also there is nothing more likely to
generate contempt from professional developers than to find a system
with hardcoded paths in it.

If you want to create inflexible code then that's entirely up to you,
but please don't pretend that there is any value to doing this except
that it allows you to be lazy.

If you're telling me you have no hard-coded paths in any of your code,
I'd
say... you're a liar.

Get over yourself.

"DFS" <nospam@dfs_.com> wrote in message
news:C9*****************@fe03.lga...

Tom van Stiphout wrote:
On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
<te*********@mps.co.uk> wrote:

But it's somewhat reasonable to assume ftp.exe is installed in the
system32 folder, which by default is in the path. Actually the use
of ComSpec assumes that as well. So one might write:
Shell "ftp.exe -s:D:\upload.txt"
That doesn't work - at least on my WinServer system. That's what
prompted my initial post.

I had to specify C:\Windows\System32\ftp, and it runs fine.


-Tom.
> Nope that''s bad advice there are a whole host of systems I've seen
> where windows is installed in the folder WinNT rather than Windows.

Hmmm... sounds ancient.

> It's poor practice to hard code variables when there is a way to
> getthe value dynamically anyway.

Probably, but the client machine uses C:\Windows\System32. So does
100% of
standard XP and Server 2003 installs.

[Lyle Fairfield]

I apologise. Because I use only sites that have both http and ftp
protocols enabled and that are MS friendly I have ignored the fact that
many are not like that and that the ADODB provider does not, TTBOMK,
recognize the FTP protocol.

[DFS]

Terry Kreft wrote:

I have clients using Win98 and I cerainly have clients using WinNT.

Hard coding paths
Never in production work, concept and testing maybe it depends on how
trivial it is.

Accusing me of lying though, pretty much sums up your attitude
That is your attitude. I'm 100% sure you have some hard-coded paths or
values out there in your code somewhere, yet you call me "lazy" for doing it
in this one instance - and in fact I *very rarely* hard-code any paths. I
usually tie them to an interface on which my users can enter or choose the
path.
doesn't it, you obviously can't even deal with the concept that there
are some people who try to do their job properly and professionally
rather than cludge it like the amateur you appear to be.

Oh, and if "getting over myself" involves falling to your standards I
think I'll pass.
But the fact is, you can't live up to your own standards.


"DFS" <nospam@dfs_.com> wrote in message
news:tL*******************@fe04.lga...

Terry Kreft wrote:

In the business world operating systems do not tend to get upgraded
until the decision to do so is forced.

You have clients still running NT on the desktop?

I spend a lot of time considering how to make my code generic and
flexible simply because there are a lot of systems out there which
are not standard installs, also there is nothing more likely to
generate contempt from professional developers than to find a system
with hardcoded paths in it.

If you want to create inflexible code then that's entirely up to
you, but please don't pretend that there is any value to doing this
except that it allows you to be lazy.

If you're telling me you have no hard-coded paths in any of your
code, I'd
say... you're a liar.

Get over yourself.

"DFS" <nospam@dfs_.com> wrote in message
news:C9*****************@fe03.lga...
Tom van Stiphout wrote:
> On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
> <te*********@mps.co.uk> wrote:
>
> But it's somewhat reasonable to assume ftp.exe is installed in the
> system32 folder, which by default is in the path. Actually the use
> of ComSpec assumes that as well. So one might write:
> Shell "ftp.exe -s:D:\upload.txt"
That doesn't work - at least on my WinServer system. That's what
prompted my initial post.

I had to specify C:\Windows\System32\ftp, and it runs fine.

>
> -Tom.
>
>
>> Nope that''s bad advice there are a whole host of systems I've
>> seen where windows is installed in the folder WinNT rather than
>> Windows.

Hmmm... sounds ancient.

>> It's poor practice to hard code variables when there is a way to
>> getthe value dynamically anyway.

Probably, but the client machine uses C:\Windows\System32. So does
100% of
standard XP and Server 2003 installs.

[Rob Oldfield]

"DFS" <nospam@dfs_.com> wrote in message
news:S1******************@fe04.lga...

From an Access 2003 module: v = Shell("ftp.exe -s:D:\ftpCommands.txt")

Contents of D:\ftpCommands.txt
----------------------------------
open ftp.destination.com
user password
send sourceFile destFile
bye
Results:
ftp> |o
invalid command
Any ideas?

Just to add another idea, why don't MS actually provide a sensible way of
accessing ftp instead of us having to resort to script files? For
reference, there's no ftp class in the 1.1 .Net framwork either.

[DFS]

Lyle Fairfield wrote:

I will just say I try not to use hard coded paths in production code.
Same here. I rarely, rarely hard code *anything*. Except in minor
instances like this, where the code will only ever run on that one XP
machine with the standard XP installation where it's been tested to work
with C:\Windows\System32.

Now when I say I try, of course, you could find hard coded paths in my
code. (e.g send e-mail with OE). It's because sometimes I'm in a
hurry, sometimes I'm careless and sometimes I've written something as
an example, which other have decided to use in production code,
(arghhhhhhh), like the OE send mail thing.
Sure. Same here.

I also hard code paths for certain systems where I require an .mdb to be
present - because that's where I decided to install it.
Does this mean that I am a liar?
Are you? Are you claiming, like Terry Kreft, that using hard-coded paths
makes me lazy, but you also do it?

I hope not. I hope it just reflects something like Joe Friday's quote:
(probably munged) "We recruit form the human race".

[Lyle Fairfield]

I don't think so.
Did you read the
"We recruit from the human race"
part?

Actually I think Terry said creating inflexible code allows you to be
lazy. Now whether "you" meant you, DFS, or you, as in the person
creating the code I don't know. And being allowed to be lazy does not
mean that one is lazy.

I'll shut up now as Terry is quite capable of speaking for himself.

[Terry Kreft]

Wrong.

Wrong again.

I will admit to one thing and that's not having some magical ability to read
your code or know what you've written in the past. Your assertion that you
are 100% certain that you know my code just seems to point to an overweaning
arogance, well I hope that's all it is anyway.
--
Terry Kreft

"DFS" <nospam@dfs_.com> wrote in message
news:_p*****************@fe02.lga...

Terry Kreft wrote:

I have clients using Win98 and I cerainly have clients using WinNT.

Hard coding paths
Never in production work, concept and testing maybe it depends on how
trivial it is.

Accusing me of lying though, pretty much sums up your attitude
I'm 100% sure you have some hard-coded paths or
values out there in your code somewhere,

<SNIP <SNIP> But the fact is, you can't live up to your own standards.

"DFS" <nospam@dfs_.com> wrote in message
news:tL*******************@fe04.lga...

Terry Kreft wrote:
In the business world operating systems do not tend to get upgraded
until the decision to do so is forced.

You have clients still running NT on the desktop?
I spend a lot of time considering how to make my code generic and
flexible simply because there are a lot of systems out there which
are not standard installs, also there is nothing more likely to
generate contempt from professional developers than to find a system
with hardcoded paths in it.

If you want to create inflexible code then that's entirely up to
you, but please don't pretend that there is any value to doing this
except that it allows you to be lazy.

If you're telling me you have no hard-coded paths in any of your
code, I'd
say... you're a liar.

Get over yourself.

"DFS" <nospam@dfs_.com> wrote in message
news:C9*****************@fe03.lga...
> Tom van Stiphout wrote:
>> On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
>> <te*********@mps.co.uk> wrote:
>>
>> But it's somewhat reasonable to assume ftp.exe is installed in the
>> system32 folder, which by default is in the path. Actually the use
>> of ComSpec assumes that as well. So one might write:
>> Shell "ftp.exe -s:D:\upload.txt"
>
>
> That doesn't work - at least on my WinServer system. That's what
> prompted my initial post.
>
> I had to specify C:\Windows\System32\ftp, and it runs fine.
>
>
>
>>
>> -Tom.
>>
>>
>>> Nope that''s bad advice there are a whole host of systems I've
>>> seen where windows is installed in the folder WinNT rather than
>>> Windows.
>
> Hmmm... sounds ancient.
>
>
>
>>> It's poor practice to hard code variables when there is a way to
>>> getthe value dynamically anyway.
>
> Probably, but the client machine uses C:\Windows\System32. So does
> 100% of
> standard XP and Server 2003 installs.

[Tom van Stiphout]

On Sat, 17 Dec 2005 22:44:04 -0000, "Rob Oldfield" <bl**@blah.com>
wrote:

Your wish is my command. See the FtpWebRequest and FtpWebResponse
classes in the framework v2.
Signed: BillG.

"DFS" <nospam@dfs_.com> wrote in message
news:S1******************@fe04.lga...

From an Access 2003 module: v = Shell("ftp.exe -s:D:\ftpCommands.txt")

Contents of D:\ftpCommands.txt
----------------------------------
open ftp.destination.com
user password
send sourceFile destFile
bye
Results:
ftp> |o
invalid command
Any ideas?

Just to add another idea, why don't MS actually provide a sensible way of
accessing ftp instead of us having to resort to script files? For
reference, there's no ftp class in the 1.1 .Net framwork either.

[DFS]

Terry Kreft wrote:

Wrong.

Wrong again.

I will admit to one thing and that's not having some magical ability
to read your code or know what you've written in the past. Your
assertion that you are 100% certain that you know my code just seems
to point to an overweaning arogance, well I hope that's all it is
anyway.
Not arrogance. It's just common knowledge that somewhere you've hard-coded
a path to a file or an .mdb. It's no crime. But hypocrisy and calling
someone lazy for doing what you yourself do is.

The routine in which I now hard-code "C:\Windows\System32\ftp -s..." has at
least 10 statements where I employ a user-defined path, such as:

AppDir = DLookup("LogLocal", "TBL_SETTINGS")
NetDir = DLookup("LogServer", "TBL_SETTINGS")
Open (AppDir & syncFileName) For Output As exportFile
FileCopy (AppDir & syncFileName), (NetDir & syncFileName)
If (FileLen(AppDir & syncFileName) = 0 ...

But near the end it has two hardcoded paths which the users don't and can't
change:

Open "D:\upload.txt" For Output As #1
Shell "C:\WINDOWS\System32\ftp -s:D:\upload.txt"

I hope you haven't billed your clients all that time you've wasted making
your systems unnecessarily "generic and flexible". Imagine if Microsoft
tried to do something similar by letting the user choose where every .dll is
installed. They would never get a product out the door.

And how about that "unprofessional, inflexible, lazy" Registry and all those
hard-coded hives and keys that the OS and most Windows programs use?

And that pesky tnsnames file Oracle requires in the <Oracle
home>\network\admin folder? Why can't I just move it to my desktop?

Are the MS and Oracle people amateur developers like you accused me of
being?

Like I said, get over yourself.




"DFS" <nospam@dfs_.com> wrote in message
news:_p*****************@fe02.lga...

Terry Kreft wrote:

I have clients using Win98 and I cerainly have clients using WinNT.

Hard coding paths
Never in production work, concept and testing maybe it depends on
how trivial it is.

Accusing me of lying though, pretty much sums up your attitude

I'm 100% sure you have some hard-coded paths or
values out there in your code somewhere,

<SNIP

<SNIP>

But the fact is, you can't live up to your own standards.

"DFS" <nospam@dfs_.com> wrote in message
news:tL*******************@fe04.lga...
Terry Kreft wrote:
> In the business world operating systems do not tend to get
> upgraded until the decision to do so is forced.

You have clients still running NT on the desktop?
> I spend a lot of time considering how to make my code generic and
> flexible simply because there are a lot of systems out there which
> are not standard installs, also there is nothing more likely to
> generate contempt from professional developers than to find a
> system with hardcoded paths in it.
>
> If you want to create inflexible code then that's entirely up to
> you, but please don't pretend that there is any value to doing
> this except that it allows you to be lazy.

If you're telling me you have no hard-coded paths in any of your
code, I'd
say... you're a liar.

Get over yourself.

> "DFS" <nospam@dfs_.com> wrote in message
> news:C9*****************@fe03.lga...
>> Tom van Stiphout wrote:
>>> On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
>>> <te*********@mps.co.uk> wrote:
>>>
>>> But it's somewhat reasonable to assume ftp.exe is installed in
>>> the system32 folder, which by default is in the path. Actually
>>> the use of ComSpec assumes that as well. So one might write:
>>> Shell "ftp.exe -s:D:\upload.txt"
>>
>>
>> That doesn't work - at least on my WinServer system. That's what
>> prompted my initial post.
>>
>> I had to specify C:\Windows\System32\ftp, and it runs fine.
>>
>>
>>
>>>
>>> -Tom.
>>>
>>>
>>>> Nope that''s bad advice there are a whole host of systems I've
>>>> seen where windows is installed in the folder WinNT rather than
>>>> Windows.
>>
>> Hmmm... sounds ancient.
>>
>>
>>
>>>> It's poor practice to hard code variables when there is a way
>>>> to getthe value dynamically anyway.
>>
>> Probably, but the client machine uses C:\Windows\System32. So
>> does 100% of
>> standard XP and Server 2003 installs.

[Terry Kreft]

You obviously have no idea what is meant by hardcoding, how OLE dlls work,
the purpose of the registry or indeed much idea of professional programming.

I evidently have nothing to learn from you and you are evidently unwilling
to learn from anyone else, so I think I'll leave your megalomanic
self-perceived omniprescience where it belongs; flapping in the ether.

<PLONK>

BTW, for any lurkers;
OLE compliant dlls can be installed anywhere; when they are registered
an entry in the registry points to the correct file.
Non-OLE compliant dlls can usually be installed anywhere in the
application folder, the path or the system folder.
Registry entries are changeable by users and therefore are not
hardcoded.
I don't know about you but I'm certainly not responsible for the
incompetence of the programmers at Oracle.

--
Terry Kreft

"DFS" <nospam@dfs_.com> wrote in message
news:mP*******************@fe07.lga...

Terry Kreft wrote:

Wrong.

Wrong again.

I will admit to one thing and that's not having some magical ability
to read your code or know what you've written in the past. Your
assertion that you are 100% certain that you know my code just seems
to point to an overweaning arogance, well I hope that's all it is
anyway.

Not arrogance. It's just common knowledge that somewhere you've
hard-coded
a path to a file or an .mdb. It's no crime. But hypocrisy and calling
someone lazy for doing what you yourself do is.

The routine in which I now hard-code "C:\Windows\System32\ftp -s..." has
at
least 10 statements where I employ a user-defined path, such as:

AppDir = DLookup("LogLocal", "TBL_SETTINGS")
NetDir = DLookup("LogServer", "TBL_SETTINGS")
Open (AppDir & syncFileName) For Output As exportFile
FileCopy (AppDir & syncFileName), (NetDir & syncFileName)
If (FileLen(AppDir & syncFileName) = 0 ...

But near the end it has two hardcoded paths which the users don't and
can't
change:

Open "D:\upload.txt" For Output As #1
Shell "C:\WINDOWS\System32\ftp -s:D:\upload.txt"

I hope you haven't billed your clients all that time you've wasted making
your systems unnecessarily "generic and flexible". Imagine if Microsoft
tried to do something similar by letting the user choose where every .dll
is
installed. They would never get a product out the door.

And how about that "unprofessional, inflexible, lazy" Registry and all
those
hard-coded hives and keys that the OS and most Windows programs use?

And that pesky tnsnames file Oracle requires in the <Oracle
home>\network\admin folder? Why can't I just move it to my desktop?

Are the MS and Oracle people amateur developers like you accused me of
being?

Like I said, get over yourself.

"DFS" <nospam@dfs_.com> wrote in message
news:_p*****************@fe02.lga...

Terry Kreft wrote:
I have clients using Win98 and I cerainly have clients using WinNT.

Hard coding paths
Never in production work, concept and testing maybe it depends on
how trivial it is.

Accusing me of lying though, pretty much sums up your attitude

I'm 100% sure you have some hard-coded paths or
values out there in your code somewhere,

<SNIP

<SNIP>

But the fact is, you can't live up to your own standards.

"DFS" <nospam@dfs_.com> wrote in message
news:tL*******************@fe04.lga...
> Terry Kreft wrote:
>> In the business world operating systems do not tend to get
>> upgraded until the decision to do so is forced.
>
> You have clients still running NT on the desktop?
>
>
>> I spend a lot of time considering how to make my code generic and
>> flexible simply because there are a lot of systems out there which
>> are not standard installs, also there is nothing more likely to
>> generate contempt from professional developers than to find a
>> system with hardcoded paths in it.
>>
>> If you want to create inflexible code then that's entirely up to
>> you, but please don't pretend that there is any value to doing
>> this except that it allows you to be lazy.
>
> If you're telling me you have no hard-coded paths in any of your
> code, I'd
> say... you're a liar.
>
> Get over yourself.
>
>
>
>
>
>> "DFS" <nospam@dfs_.com> wrote in message
>> news:C9*****************@fe03.lga...
>>> Tom van Stiphout wrote:
>>>> On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
>>>> <te*********@mps.co.uk> wrote:
>>>>
>>>> But it's somewhat reasonable to assume ftp.exe is installed in
>>>> the system32 folder, which by default is in the path. Actually
>>>> the use of ComSpec assumes that as well. So one might write:
>>>> Shell "ftp.exe -s:D:\upload.txt"
>>>
>>>
>>> That doesn't work - at least on my WinServer system. That's what
>>> prompted my initial post.
>>>
>>> I had to specify C:\Windows\System32\ftp, and it runs fine.
>>>
>>>
>>>
>>>>
>>>> -Tom.
>>>>
>>>>
>>>>> Nope that''s bad advice there are a whole host of systems I've
>>>>> seen where windows is installed in the folder WinNT rather than
>>>>> Windows.
>>>
>>> Hmmm... sounds ancient.
>>>
>>>
>>>
>>>>> It's poor practice to hard code variables when there is a way
>>>>> to getthe value dynamically anyway.
>>>
>>> Probably, but the client machine uses C:\Windows\System32. So
>>> does 100% of
>>> standard XP and Server 2003 installs.

[DFS]

Terry Kreft wrote:

You obviously have no idea what is meant by hardcoding, how OLE dlls
work, the purpose of the registry or indeed much idea of professional
programming.
I take it you found some hard-coded paths in your code, and have decided to
take your ball home from the playground. Good. That's known as getting
over yourself.
I evidently have nothing to learn from you and you are evidently
unwilling to learn from anyone else, so I think I'll leave your
megalomanic self-perceived omniprescience where it belongs; flapping
in the ether.

<PLONK>
Smart move.
BTW, for any lurkers;
OLE compliant dlls can be installed anywhere; when they are
registered an entry in the registry points to the correct file.
Now tell me how I can install them to different places but retain a
functional system. What's that? I can't, because the programs expect them
to be in certain, hard-coded locations? But that's "poor practice,
amateurish, unprofessional, etc etc."?
Non-OLE compliant dlls can usually be installed anywhere in the
application folder, the path or the system folder.
I want to put them somewhere else. You say it's unprofessional to hard-code
any file locations/paths. But I'd say 99% of programs in use look for fixed
file locations. So, either you're wrong or everyone else is.

I put my money on you being wrong.
Registry entries are changeable by users and therefore are not
hardcoded.
The locations of the keys are hard-coded within the hive, and most Windows
programs write keys to fixed locations, ala HKEY_LOCAL_MACHINE\SOFTWARE\.

Now what kind of incompetent, inflexible, amateur, unprofessional developer
at MS designed that?

He obviously never spoke to cdma weenie Terry Kreft.
I don't know about you but I'm certainly not responsible for the
No, you're just responsible for your own delusions about being
"professional" while everyone else is an "amateur" who follows poor
programming practices.
incompetence of the programmers at Oracle.
LOL!


"DFS" <nospam@dfs_.com> wrote in message
news:mP*******************@fe07.lga...

Terry Kreft wrote:

Wrong.

Wrong again.

I will admit to one thing and that's not having some magical ability
to read your code or know what you've written in the past. Your
assertion that you are 100% certain that you know my code just seems
to point to an overweaning arogance, well I hope that's all it is
anyway.

Not arrogance. It's just common knowledge that somewhere you've
hard-coded
a path to a file or an .mdb. It's no crime. But hypocrisy and
calling someone lazy for doing what you yourself do is.

The routine in which I now hard-code "C:\Windows\System32\ftp -s..."
has at
least 10 statements where I employ a user-defined path, such as:

AppDir = DLookup("LogLocal", "TBL_SETTINGS")
NetDir = DLookup("LogServer", "TBL_SETTINGS")
Open (AppDir & syncFileName) For Output As exportFile
FileCopy (AppDir & syncFileName), (NetDir & syncFileName)
If (FileLen(AppDir & syncFileName) = 0 ...

But near the end it has two hardcoded paths which the users don't and
can't
change:

Open "D:\upload.txt" For Output As #1
Shell "C:\WINDOWS\System32\ftp -s:D:\upload.txt"

I hope you haven't billed your clients all that time you've wasted
making your systems unnecessarily "generic and flexible". Imagine
if Microsoft tried to do something similar by letting the user
choose where every .dll is
installed. They would never get a product out the door.

And how about that "unprofessional, inflexible, lazy" Registry and
all those
hard-coded hives and keys that the OS and most Windows programs use?

And that pesky tnsnames file Oracle requires in the <Oracle
home>\network\admin folder? Why can't I just move it to my desktop?

Are the MS and Oracle people amateur developers like you accused me
of being?

Like I said, get over yourself.

"DFS" <nospam@dfs_.com> wrote in message
news:_p*****************@fe02.lga...
Terry Kreft wrote:
> I have clients using Win98 and I cerainly have clients using
> WinNT.
>
> Hard coding paths
> Never in production work, concept and testing maybe it depends on
> how trivial it is.
>
> Accusing me of lying though, pretty much sums up your attitude

I'm 100% sure you have some hard-coded paths or
values out there in your code somewhere,
<SNIP

<SNIP>
But the fact is, you can't live up to your own standards.

> "DFS" <nospam@dfs_.com> wrote in message
> news:tL*******************@fe04.lga...
>> Terry Kreft wrote:
>>> In the business world operating systems do not tend to get
>>> upgraded until the decision to do so is forced.
>>
>> You have clients still running NT on the desktop?
>>
>>
>>> I spend a lot of time considering how to make my code generic
>>> and flexible simply because there are a lot of systems out
>>> there which are not standard installs, also there is nothing
>>> more likely to generate contempt from professional developers
>>> than to find a system with hardcoded paths in it.
>>>
>>> If you want to create inflexible code then that's entirely up to
>>> you, but please don't pretend that there is any value to doing
>>> this except that it allows you to be lazy.
>>
>> If you're telling me you have no hard-coded paths in any of your
>> code, I'd
>> say... you're a liar.
>>
>> Get over yourself.
>>
>>
>>
>>
>>
>>> "DFS" <nospam@dfs_.com> wrote in message
>>> news:C9*****************@fe03.lga...
>>>> Tom van Stiphout wrote:
>>>>> On Fri, 16 Dec 2005 01:31:49 -0000, "Terry Kreft"
>>>>> <te*********@mps.co.uk> wrote:
>>>>>
>>>>> But it's somewhat reasonable to assume ftp.exe is installed in
>>>>> the system32 folder, which by default is in the path. Actually
>>>>> the use of ComSpec assumes that as well. So one might write:
>>>>> Shell "ftp.exe -s:D:\upload.txt"
>>>>
>>>>
>>>> That doesn't work - at least on my WinServer system. That's
>>>> what prompted my initial post.
>>>>
>>>> I had to specify C:\Windows\System32\ftp, and it runs fine.
>>>>
>>>>
>>>>
>>>>>
>>>>> -Tom.
>>>>>
>>>>>
>>>>>> Nope that''s bad advice there are a whole host of systems
>>>>>> I've seen where windows is installed in the folder WinNT
>>>>>> rather than Windows.
>>>>
>>>> Hmmm... sounds ancient.
>>>>
>>>>
>>>>
>>>>>> It's poor practice to hard code variables when there is a way
>>>>>> to getthe value dynamically anyway.
>>>>
>>>> Probably, but the client machine uses C:\Windows\System32. So
>>>> does 100% of
>>>> standard XP and Server 2003 installs.