On Fri, 03 Apr 2009, Adam Lubszczyk wrote:
Hi,
> > Problem:
> > In Clipper or FoxPro samebody create index like:
> > INDEX ON Name_and_Last TO xxx
> > but field name in DBF is 'NAME_AND_L'.
> > In Clipper and FoxPro it's work OK
> > but Harbour when open index show error:
> > variable 'Name_and_Last' not found.
> > (in index file key is 'Name_and_Last' )
> > How open and work with this index in Harbour ?
It's a problem. Probably I can hack some extension to DBF* RDDs
and dynamically updated long field names if they refer to current
WA fields but in longer terms such hacks create problems when
user really want to use long symbols so such feature will have
to be enabled optionally only on user request by some RDDI_*
action, f.e.:
rddInfo( RDDI_FNAMETRANS, .t., "DBFCDX" )
> Mayby You add "Alias Symbol" like:
> SETALIAS VariableWithLongName FOR VariableWi
> SETALIAS FunctionWithLongName() FOR FunctionWi()
> SETSHORTALIAS VariableWithLongName , FunctionWithLongName() //auto set alias
> for 10 lenght original
It does not resolve the problem because you will have to add many
different aliases for the same name with 10, 11, 12, ... characters.
People have a lot of typos in source code after 10-th character.
Static compile time aliassing does not resolve the problem with macro
compiler so such feature have to be implemented at runtime otherwise
people will still finding some problems and we only make it harder
to locate and fix.
Only global reducing to 10 significant characters resolve the problem
but this is very serious limitation.
So the final answer has to be: clean the code to use exact names.
The exception is RDD subsystem and field names. Here different RDDs
has different field name size limits and different restrictions to
supported field names.
F.e. even in Clipper you can use as field name: "A+B" but later you
will not be able to access it directly and you will have to use
fieldpos()/fieldget()/fieldput(). Some RDDs allow to use spaces in
field names, f.e. "ZIP CODE" and such fields also cannot be accessed
directly. So here some aliasing system can be interesting alternative.
But the question is how deeply we should implement it. If we do not
make original names invisible then people will still have problems
with some code like:
for i := 1 to fcount()
oBrw:AddColumn( TBColumnNew( FieldName( i ), ;
&( "{||" + FieldName( i ) + "}" ) ) )
next
FieldName(), dbstruct(), etc. have to return aliased names only to
compatible with macro compiler.
If we fully hide original names by aliases then we lost them in
COPY TO / APPEND FROM operations but IMHO it's the smallest cost we
have to pay in comparison to other solutions.
It's not trivial to resolve problem without introducing some other problems
or anomalies but unlike with variables and function names in RDD case we
cannot say that programmer should clean his .prg code because it may not
be enough due to field name convention which comes from some foreign
database system and is not Clipper/Harbour compatible at all.
So sooner or later we will have to think about some helper solution but
it will be local to RDD only.
Now user can create some local translation systems customized for their
own needs using USRRDD to create some simple wrappers to existing RDDs
or use fieldpos()/fieldget()/fieldput().
For memvars (public and private variables) they can make some
RT tricks like:
proc main()
public myvar1_localdata := "abc"
public myvar1_loc := iif( .t., @myvar1_localdata, )
? myvar1_localdata, myvar1_loc
myvar1_loc := upper( myvar1_loc )
? myvar1_localdata, myvar1_loc
return
just like for functions:
func my_longfunctionname()
[...]
func my_longfun()
return my_longfunctionname()
depending on existing source code it may be enough or not.
There is still problem with Clipper code which makes things like:
dbSelectAreaForSaleTable( 2 )
In Clipper only 10 character are significant so some people used
others as some type of comment. In such case only global cuting all
symbols to 10 characters can help. It's good if these are functions
called explicitly because they can be easy caught and fixed at compile
time but if they are used in macro compiler then compilation and linking
passes without any warnings but later they have RT errors.
Any aliasing system will help them. It's necessary to carefully
check the whole source code.
> Now, VariableWithLongName and VariableWi on the same variable,
> FunctionWithLongName() and FunctionWi() on the same function.
See above. Thanks for the suggestions but if you analyze the
problem deeply then you will find that only global symbol length
reduction to 10 characters can give full Clipper compatibility.
All other solutions only moves the problem. They can help some
people but do not some others so they are rather efficient only
as some local workarounds not as general core code feature.
For RDDs we can try to introduce some exceptions as workaround
for some different low level RDD driver field name conventions
but they should be local to given RDDs and always optional.
Just like adopting index KEY and FOR expressions to table field
names like in your example. Maybe I'll add it in some spare time
to DBF* RDDs.
In core code we probably can only add one simple feature as
DBI_* action, f.e.:
dbInfo( DBI_SETFIELDNAME, { <nField>, <cNewFieldName> } )
so user can make some customized RDDs or simply use wrapper
to dbUseArea() which will open table (.dbf) and then some
initialization file (<table name>.ini) and set new field names
to aliases defined inside using DBI_SETFIELDNAME.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
