Vista install -- characters dropped from field names on new table creation

[Geep Howell]

I have an ap that maintains data for our local police academy.
Everything runs fine on XP. DEO files are kept on a file server
(running NT 4.0, sorta old and slow but still functional...) as is all
the data.

One of my main users had her computer replaced several days ago with a
Dell machine running Vista Home. When I installed my ap, I had some
problems, so I recompiled the ap at home using the latest INNO,
created a setup file, and reinstalled everything today, but the same
error persists. I can't get it to exhibit the problem behavior in the
home environment, running it on a similar Dell machine, same OS, and
my file server, which is a ClarkConnect system running CentOS, files
shared with Samba.

She logs in to Vista as an administrator. Both machines are patched
with Service Pack 1. User account control is turned off as is the
Windows firewall.

I use a PRG file when the program opens to delete and re-create the
three temp tables that are used on the user workstation. Certain
routines in the main program write data to the temp tables for
processing, then return the data to the main tables on the file
server.

The Academy version fails when writing to a local table on the user
machine within the ap subdirectory. The error is "subscript not
found" and when I copied the table over to my work machine where Plus
is installed, and looked at the structure, I found that the row names
of the two fields that were failing were truncated. CS_END_DATE
became CS_END_DA. Hard for the program to find.

I can't repeat this behavior on my home system. Nor have I ever seen
it happen at the Academy with the XP machines.

Any ideas on what might be happening? I am running 2.6.1.5 with the
2083 runtime. TIA

Geep

[Greg Hill]

Post by Geep Howell
I have an ap that maintains data for our local police academy.
Everything runs fine on XP. DEO files are kept on a file server
(running NT 4.0, sorta old and slow but still functional...) as is all
the data.
One of my main users had her computer replaced several days ago with a
Dell machine running Vista Home. When I installed my ap, I had some
problems, so I recompiled the ap at home using the latest INNO,
created a setup file, and reinstalled everything today, but the same
error persists. I can't get it to exhibit the problem behavior in the
home environment, running it on a similar Dell machine, same OS, and
my file server, which is a ClarkConnect system running CentOS, files
shared with Samba.
She logs in to Vista as an administrator. Both machines are patched
with Service Pack 1. User account control is turned off as is the
Windows firewall.
I use a PRG file when the program opens to delete and re-create the
three temp tables that are used on the user workstation. Certain
routines in the main program write data to the temp tables for
processing, then return the data to the main tables on the file
server.
The Academy version fails when writing to a local table on the user
machine within the ap subdirectory. The error is "subscript not
found" and when I copied the table over to my work machine where Plus
is installed, and looked at the structure, I found that the row names
of the two fields that were failing were truncated. CS_END_DATE
became CS_END_DA. Hard for the program to find.
I can't repeat this behavior on my home system. Nor have I ever seen
it happen at the Academy with the XP machines.
Any ideas on what might be happening? I am running 2.6.1.5 with the
2083 runtime. TIA

I didn't read your post thoroughly but my guess is:
Something to do with the font size of the theme in Vista. I am sure you can
customize the Themes and get it right through Vista Display Properties.

Greg Hill

[Geep]

Post by Greg Hill
Something to do with the font size of the theme in Vista. I am sure you can
customize the Themes and get it right through Vista Display Properties.
Greg Hill

Not sure I understand why font size would affect the data structure of
the table. It isn't a problem with the display of the field on
screen, rather, the field name is actually being truncated when
written to the new table. So a field called CS_INS_DATE ( for
Courtroom Security InService Date) is written to the table as
CS_INS_DA. The "TE" is removed. When I refer to that field by its
correct name, it can't be found and I get a subscript error. Same
thing with the DISP_INS_DATE, which comes out DISP_INS_D. It is also
interesting that these are the only two fields affected from some 40
fields in the table.

I had guessed that the name length might have something to do with the
problem, but the CS field is cut to 9 places where the DISP field is
cut to 10.

Scratching my head...

Thanks

Geep

[Greg Hill]

Ok, now that I have read more details, I think I know what it is.
The BDE can be set to different levels for backwards compatibility.
It sounds like your LEVEL 7 tables have been reverted back to a LEVEL less
than 7, those table structures only allow for 10 or eleven character titles.

It can also cause other problems if you used some of the newer field types.

You will need to drill into the BDE, click the "Configuration" tab, then
expand the tree of Drivers, then Native Drivers, then dBASE (I would
assume).
Then change the LEVEL to 7.
If you do this, then restart dBASE, it won't have any affect until you
actually make a change to the structure then save it, it will then be a new
LEVEL of 7.

So you will need to find a backup of your table structure when it was LEVEL
7 and then copy it into the folder for use and populate it.
You should be good to go after that.

Hopefully that helps.
Greg Hill

[*Lysander*]

Post by Geep Howell
Any ideas on what might be happening? I am running 2.6.1.5 with the
2083 runtime. TIA

Take a close look at the BDE.
New machine always means new installation of BDE.

Table level could be reduced to 4 or 5, instead of 7.
Fieldnames will be truncated to 10 chars, though I fail to figure why
one would be reduced to 9.

BDE's worth checking, though.

[Chris Stoeckert]

Hi Geep --
FWIW, I have the same aps running on both XP and Vista machines -- without
any problems. I can't think of a logical reason why the field names are
being changed (truncated) when the new temp tables are created by the PRG
file unless there is a problem with that file (you might consider posting a
copy in this newsgroup).
You might also consider changing the PRG file to "empty" the tables instead
of deleting and recreating them (that's a method I use <g>) which enables me
to retain both the original file structure and field names.
HTH, Chris

Post by Geep Howell
I have an ap that maintains data for our local police academy.
Everything runs fine on XP. DEO files are kept on a file server
(running NT 4.0, sorta old and slow but still functional...) as is all
the data.
One of my main users had her computer replaced several days ago with a
Dell machine running Vista Home. When I installed my ap, I had some
problems, so I recompiled the ap at home using the latest INNO,
created a setup file, and reinstalled everything today, but the same
error persists. I can't get it to exhibit the problem behavior in the
home environment, running it on a similar Dell machine, same OS, and
my file server, which is a ClarkConnect system running CentOS, files
shared with Samba.
She logs in to Vista as an administrator. Both machines are patched
with Service Pack 1. User account control is turned off as is the
Windows firewall.
I use a PRG file when the program opens to delete and re-create the
three temp tables that are used on the user workstation. Certain
routines in the main program write data to the temp tables for
processing, then return the data to the main tables on the file
server.
The Academy version fails when writing to a local table on the user
machine within the ap subdirectory. The error is "subscript not
found" and when I copied the table over to my work machine where Plus
is installed, and looked at the structure, I found that the row names
of the two fields that were failing were truncated. CS_END_DATE
became CS_END_DA. Hard for the program to find.
I can't repeat this behavior on my home system. Nor have I ever seen
it happen at the Academy with the XP machines.
Any ideas on what might be happening? I am running 2.6.1.5 with the
2083 runtime. TIA
Geep

[Geep]

On Tue, 28 Oct 2008 21:33:27 -0700, "Chris Stoeckert"
<***@verizon.net> wrote:
Hi Chris,

Originally I did empty the temp tables, but ran into some problems
with local users doing stuff that they shouldn't, so I elected to just
re-write them each time. It goes very quickly and has not caused
problems up to now...

Others have suggested that the BDE has somehow gotten set to level 5
tables, and that may be the case, I will check a little later today.
If that isn't the case, I will take your suggestion and put the
entire PRG file up for a pick apart exercise! I am not a pro at this,
though I have been writing dBase stuff for the last 30 years, so I
expect my code could certainly be improved.

Thanks for the comments.

geep

Post by Chris Stoeckert
Hi Geep --
FWIW, I have the same aps running on both XP and Vista machines -- without
any problems. I can't think of a logical reason why the field names are
being changed (truncated) when the new temp tables are created by the PRG
file unless there is a problem with that file (you might consider posting a
copy in this newsgroup).
You might also consider changing the PRG file to "empty" the tables instead
of deleting and recreating them (that's a method I use <g>) which enables me
to retain both the original file structure and field names.
HTH, Chris

[Geoff Wass [dBVIPS]]

Post by Geep Howell
I have an ap that maintains data for our local police academy.
Everything runs fine on XP. DEO files are kept on a file server
(running NT 4.0, sorta old and slow but still functional...) as is all
the data.
One of my main users had her computer replaced several days ago with a
Dell machine running Vista Home. When I installed my ap, I had some
problems, so I recompiled the ap at home using the latest INNO,
created a setup file, and reinstalled everything today, but the same
error persists. I can't get it to exhibit the problem behavior in the
home environment, running it on a similar Dell machine, same OS, and
my file server, which is a ClarkConnect system running CentOS, files
shared with Samba.
She logs in to Vista as an administrator. Both machines are patched
with Service Pack 1. User account control is turned off as is the
Windows firewall.
I use a PRG file when the program opens to delete and re-create the
three temp tables that are used on the user workstation. Certain
routines in the main program write data to the temp tables for
processing, then return the data to the main tables on the file
server.
The Academy version fails when writing to a local table on the user
machine within the ap subdirectory. The error is "subscript not
found" and when I copied the table over to my work machine where Plus
is installed, and looked at the structure, I found that the row names
of the two fields that were failing were truncated. CS_END_DATE
became CS_END_DA. Hard for the program to find.
I can't repeat this behavior on my home system. Nor have I ever seen
it happen at the Academy with the XP machines.
Any ideas on what might be happening? I am running 2.6.1.5 with the
2083 runtime. TIA
Geep

Geep,

If the *names* of the fields are changing, it is likey the BDE setting
is for, say, level 4 or 5 tables which support a maximum name of
characters rather than level 7 which supports name that are 31 (or 32)
characters long. You will encounter problems if you COPY a table or
modify the structure of a table, etc. Anything which creates a new
table, even if only a temporary one.

[Robert Bravery]

HI Geep,
As other sugest. Check you BDe settings on the new instalation. Make sure
you have the correct table level setting. This sounds like a table level
problem where older versions, table 5, only allowed 8-10 (can't remember
which) character for the field names.

Robert

Post by Geep Howell
I have an ap that maintains data for our local police academy.
Everything runs fine on XP. DEO files are kept on a file server
(running NT 4.0, sorta old and slow but still functional...) as is all
the data.
One of my main users had her computer replaced several days ago with a
Dell machine running Vista Home. When I installed my ap, I had some
problems, so I recompiled the ap at home using the latest INNO,
created a setup file, and reinstalled everything today, but the same
error persists. I can't get it to exhibit the problem behavior in the
home environment, running it on a similar Dell machine, same OS, and
my file server, which is a ClarkConnect system running CentOS, files
shared with Samba.
She logs in to Vista as an administrator. Both machines are patched
with Service Pack 1. User account control is turned off as is the
Windows firewall.
I use a PRG file when the program opens to delete and re-create the
three temp tables that are used on the user workstation. Certain
routines in the main program write data to the temp tables for
processing, then return the data to the main tables on the file
server.
The Academy version fails when writing to a local table on the user
machine within the ap subdirectory. The error is "subscript not
found" and when I copied the table over to my work machine where Plus
is installed, and looked at the structure, I found that the row names
of the two fields that were failing were truncated. CS_END_DATE
became CS_END_DA. Hard for the program to find.
I can't repeat this behavior on my home system. Nor have I ever seen
it happen at the Academy with the XP machines.
Any ideas on what might be happening? I am running 2.6.1.5 with the
2083 runtime. TIA
Geep
---
avast! Antivirus: Inbound message clean.
Virus Database (VPS): 081028-1, 28/10/2008
Tested on: 29/10/2008 09:19:05 AM
avast! - copyright (c) 1988-2008 ALWIL Software.
http://www.avast.com

--
Web Development, Hosting, Design and Content Management Systems
http://www.integralwebsolutions.co.za



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 081028-1, 28/10/2008
Tested on: 29/10/2008 09:23:11 AM
avast! - copyright (c) 1988-2008 ALWIL Software.
http://www.avast.com

[Geep]

You folks are the best! I checked the 3 temp tables and they are, in
fact, level 4 tables. In addition, I had the fieldname wrong for one
of them the CS_INS_DATE field had only the "E" dropped off, taking it
to ten characters.

So I am off to visit my friends at the Academy and correct the
problem.

It's always good to learn something new as well as fix a problem, so
once again, many thanks to everyone who posted as well as a huge
thanks for responding so quickly.

Geep

[Geoff Wass [dBVIPS]]

Post by Geep
You folks are the best! I checked the 3 temp tables and they are, in
fact, level 4 tables. In addition, I had the fieldname wrong for one
of them the CS_INS_DATE field had only the "E" dropped off, taking it
to ten characters.
So I am off to visit my friends at the Academy and correct the
problem.
It's always good to learn something new as well as fix a problem, so
once again, many thanks to everyone who posted as well as a huge
thanks for responding so quickly.
Geep

Geep,

Thanks for the success report. Ronnie MacGregor has a custom control
that lets your program check the BDE settings when you start your proram
and can reset incorrect settings. It is called rmBDEConfig. You can find
it here: http://www.dbasedeveloper.co.uk/

[Geep]

Hi All,

Seems that the BDE configuration is the top vote getter in fixing this
problem, so I will travel back down to the Academy and check. I have
copies of the tables that were created here and should be able to tell
if they are level 5 or level 7. If the BDE is indeed the culprit,
that should be easy to fix.

Thanks very much to everyone who made suggestions!! I don't think I
would have thought of this without all the helpful suggestions.

Geep