dBASE Bugs - Macro substitution bug.

Author

Macro substitution bug.

Les Shewchuk

2006-04-07, 1:30 pm

This may be hard to track or duplicate as it seems to be intermittent.

cPath = " E:\Program\Data\Back
up\INV" + dtos(date())
mkdir &cPath.

(and, yes, I tried a variety of quotations around the path to get e:\ "e:\
and 'e:\ )

Sometimes it works and creates a folder in the correct location called (for
today) INV20060607 .

Other times it tries to create a folder called &cpath.

Strangely, On XP home (where I tested this) windows created the folder
&cpath and the program continued. It would then throw an error when it
tried to put files in the INV20060607 folder, to discover it didn't exist.

I'd look for a problem. Try something difference and re-compile the form.
Sometimes it worked, sometimes it didn't.

Where I deployed the program (when it worked for a while), the folder would
be located on a windows 200 server. Again, it tried to create a folder
called &cPath. There the O/S rejected the & in the folder name and threw an
error.

Workaround

CmdMD = 'mkdir " e:\program\data\back
up\INV' + dtos(date()) + '"'
&CmdMD.

I have no clue why this is happening. I've used this many times before.
It's taken right from the TRY...CATCH example.

Les Shewchuk

Mike Nunn

2006-04-07, 8:26 pm

I use this and
"Les Shewchuk" <les@tritonmarine.com> wrote in message
news:AXlezbmWGHA.1548@news-server...
> This may be hard to track or duplicate as it seems to be intermittent.
>
> cPath = " E:\Program\Data\Back
up\INV" + dtos(date())
> mkdir &cPath.
>
> (and, yes, I tried a variety of quotations around the path to get e:\ "e:\
> and 'e:\ )
>
> Sometimes it works and creates a folder in the correct location called
> (for today) INV20060607 .
>
> Other times it tries to create a folder called &cpath.
>
> Strangely, On XP home (where I tested this) windows created the folder
> &cpath and the program continued. It would then throw an error when it
> tried to put files in the INV20060607 folder, to discover it didn't exist.
>
> I'd look for a problem. Try something difference and re-compile the form.
> Sometimes it worked, sometimes it didn't.
>
> Where I deployed the program (when it worked for a while), the folder
> would be located on a windows 200 server. Again, it tried to create a
> folder called &cPath. There the O/S rejected the & in the folder name and
> threw an error.
>
> Workaround
>
> CmdMD = 'mkdir " e:\program\data\back
up\INV' + dtos(date()) + '"'
> &CmdMD.
>
> I have no clue why this is happening. I've used this many times before.
> It's taken right from the TRY...CATCH example.
>
> Les Shewchuk
>

Mike Nunn

2006-04-07, 8:26 pm

I use this method - though with a 'numeric string' rather than a 'date
string' and haven't found a problem. Your example code doesn't have a space
in the path/file name, but is that ever the case?

Mike

"Les Shewchuk" <les@tritonmarine.com> wrote in message
news:AXlezbmWGHA.1548@news-server...
> This may be hard to track or duplicate as it seems to be intermittent.
>
> cPath = " E:\Program\Data\Back
up\INV" + dtos(date())
> mkdir &cPath.
>
> (and, yes, I tried a variety of quotations around the path to get e:\ "e:\
> and 'e:\ )
>
> Sometimes it works and creates a folder in the correct location called
> (for today) INV20060607 .
>
> Other times it tries to create a folder called &cpath.
>
> Strangely, On XP home (where I tested this) windows created the folder
> &cpath and the program continued. It would then throw an error when it
> tried to put files in the INV20060607 folder, to discover it didn't exist.
>
> I'd look for a problem. Try something difference and re-compile the form.
> Sometimes it worked, sometimes it didn't.
>
> Where I deployed the program (when it worked for a while), the folder
> would be located on a windows 200 server. Again, it tried to create a
> folder called &cPath. There the O/S rejected the & in the folder name and
> threw an error.
>
> Workaround
>
> CmdMD = 'mkdir " e:\program\data\back
up\INV' + dtos(date()) + '"'
> &CmdMD.
>
> I have no clue why this is happening. I've used this many times before.
> It's taken right from the TRY...CATCH example.
>
> Les Shewchuk
>

Les Shewchuk

2006-04-07, 8:26 pm

At my client. No spaces.
At my home Yes, there are spaces.
At my office, Both with and without spaces...But it seems to work here.

the Date string is characters. dtos(date()) converts the date to YYYYMMDD
as text and a folder with 11 characters is not uncommon these days.

The odd part is actually seeing a folder called &cPath being created.

And It did start working correctly again (or else I would never have tried
to deploy it to the customer)

So I don't know WHAT is going on.

I seem to have a knack for finding bugs that are not always dBases fault,
but when it interacts with the operating system...and the O/S changes.

Les

"Mike Nunn" <mbnunnuk@yahoo.co.uk> wrote in message
news:iQn5sPnWGHA.1548@news-server...
>I use this method - though with a 'numeric string' rather than a 'date
>string' and haven't found a problem. Your example code doesn't have a
>space in the path/file name, but is that ever the case?
>
> Mike
>
>
>
> "Les Shewchuk" <les@tritonmarine.com> wrote in message
> news:AXlezbmWGHA.1548@news-server...
>
>

Mike Nunn

2006-04-07, 8:26 pm

Les

I asked about spaces because that did create a problem for me at one time.

This might be worth a try if you haven't already:

cPath = "& #91;E:\Program\Data\
Backup\INV" + dtos(date()) + "]"

Mike

"Les Shewchuk" <les@tritonmarine.com> wrote in message
news:z07LiunWGHA.1824@news-server...
> At my client. No spaces.
> At my home Yes, there are spaces.
> At my office, Both with and without spaces...But it seems to work here.
>
> the Date string is characters. dtos(date()) converts the date to YYYYMMDD
> as text and a folder with 11 characters is not uncommon these days.
>
> The odd part is actually seeing a folder called &cPath being created.
>
> And It did start working correctly again (or else I would never have tried
> to deploy it to the customer)
>
> So I don't know WHAT is going on.
>
> I seem to have a knack for finding bugs that are not always dBases fault,
> but when it interacts with the operating system...and the O/S changes.
>
> Les
>
> "Mike Nunn" <mbnunnuk@yahoo.co.uk> wrote in message
> news:iQn5sPnWGHA.1548@news-server...
>
>

Bruce Beacham

2006-04-07, 8:26 pm

Les Shewchuk wrote:

> cPath = " E:\Program\Data\Back
up\INV" + dtos(date())
> mkdir &cPath.
>
> (and, yes, I tried a variety of quotations around the path to get e:\ "e:\
> and 'e:\ )
>
> Sometimes it works and creates a folder in the correct location called (for
> today) INV20060607 .
>
> Other times it tries to create a folder called &cpath.

May I diffidently check that cpath is always a private variable?

Bruce Beacham

Les Shewchuk

2006-04-07, 8:26 pm

Private, Yup. Created on the fly just before it's needed.

In this case, the e:\Program\Data\Back
up portion is fixed. This had to do
with how the original programmer designed the system. Other times I have
retrieved the path from BDE Alias (to get the e:\program\Data portion.) and
then added on the desired sub-folder(s)

Just to be safe while I was testing, I even had gone MSGBOX("|"+cPath+"|")
just to show me what was being used, just in case I goofed something up.

It's confused me. Sometimes it works, sometimes it doesn't. I haven't
encountered it in the office, but I have at home where it goofed a few times
then started working, then goofed again with I put the .wfo on the client's
site.

I know how hard it is to track down something that doesn't happen all the
time. And, yes, it could just be something on my home machine. Or it could
be an update in something else that is now interfering with dBase.

What Is happening here is before certain points in the program, an automatic
backup of the data is made. I don't use the database .copyTable() as this is
going to a different folder. It's a lot faster as the COPY TABLE command
actually calls the O/S copy command for each file (DBF, DBT, MDX) and, since
it is an O/S level copy, it avoids a problem we have been having with a
"read error" once the file gets over a certain size.

Les Shewchuk

"Bruce Beacham" <bbeacham@beacham.no-spam.co.uk> wrote in message
news:VNN0wQoWGHA.1824@news-server...
> Les Shewchuk wrote:
>
>
> May I diffidently check that cpath is always a private variable?
>
>
> Bruce Beacham
>

Les Shewchuk

2006-04-07, 8:26 pm

I don't think I tried that combination.

I think I avoided it because the path with spaces needs a " or ' when you're
using the command prompt. The [ ] for strings is dBase, not DOS/Windows.

Will give it a try though

Les

"Mike Nunn" <mbnunnuk@yahoo.co.uk> wrote in message
news:EmIkHKoWGHA.1824@news-server...
> Les
>
> I asked about spaces because that did create a problem for me at one time.
>
> This might be worth a try if you haven't already:
>
> cPath = "& #91;E:\Program\Data\
Backup\INV" + dtos(date()) + "]"
>
> Mike
>
>
>
> "Les Shewchuk" <les@tritonmarine.com> wrote in message
> news:z07LiunWGHA.1824@news-server...
>
>

Bruce Beacham

2006-04-08, 3:26 am

Les Shewchuk wrote:
> Private, Yup. Created on the fly just before it's needed.

I assume with an explicit private declaration at that time.

OK. Is cpath used as a variable or field name _anywhere_ else in
your code, which could be lingering in memory when this function is
called? Perhaps in a library or subfunction or even in a dUFLP
function you call at any time? (I have had this very problem).

Perhaps use a more individual name instead of cpath , just to be sure?

Bruce

Jean-Pierre Martel

2006-04-08, 3:26 am

In article <z07LiunWGHA.1824@news-server>, les@tritonmarine.com says...
>
> At my home Yes, there are spaces.

Then:

PRIVATE cPath
cPath = "This folder name has spaces"
md "&cPath"

Jean-Pierre Martel, editor
The dBASE Developers Bulletin
Blue Star dBASE Plus Core Concepts Graduate

Sponsored Links