×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

updating table with a .cdx

updating table with a .cdx

updating table with a .cdx

(OP)
Hi,

Griff constgructed an indexroutine

CODE --> vfp

Function HIERACHY
	Parameters m.KeyField
	PRIVATE m.KeyField,m.String, m.WordCount, I 
	m.Wordcount = GetWordCount(m.KeyField,".")
	m.String = STR(m.WordCount,3,0)
	For I = 1 to m.WordCount
		m.String = m.String + STR(VAL(GetWordNum((m.KeyField,I,".")),3,0)
	Next
	Return(m.String) 

which works perfectly.
This procedure will create a .cdx file. When updating my table it errors "The nonstructural CDX file should be closed"
Is there a construction/coding possible to have this indexroutine as index part of the table to overcome this error?

Stay healthy,
Koen

RE: updating table with a .cdx

Koen, could you please explain how this routine is used (or link back to Griff's original post)? I can see what the code is doing, but it is not clear how that relates to the CDX.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: updating table with a .cdx

That said, I assume from the error message that you are trying to create a structural CDX (one whose name is the same as the DBF), but another CDX (with a different name) is currently in force.

If that's the case, all you need to do is to issue CLOSE INDEXES. That will close the non-structural index, but allow the structural index to be opened or remain open.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: updating table with a .cdx

You rarely create a CDX, you create a tag in the main CDX of a table, you create this main CDX when you issue the first INDEX ON expression TAG tagname for a DBF or create the first index in the table designer.

And the only thing that's special about using a function in an index expression is, that SET PROCEDURE must make this function available, or usage of the CDX gets in trouble. Remember the main CDX of a table will be maintained automatically. If you update data or insert a new record all tags of the main CDX will need an update and for that to work the Hierarchy function must be visible to VFP. Besides that specialty for indexes based on user-defined functions, there is nothing special about updating a table which has a cdx besides perhaps also an fpt, you only USE the DBF, any memo like fields automatically go into the fpt and any index changes due to data changes automatically go into the CDX. For this to be possible in case an index expression uses a function, well, as already said, VFP must know where to find that to be able to call it.

I guess the problem is somewhere here.

You can create secondary CDXes when you use the OF CDXFilename clause of the INDEX command, but I doubt you do. Then there can be any number of additional IDX files, but they play no role anymore, could be used for temp indexes, but I doubt that you use the hierarchy only temporary and that you put this in an extra idx or cdx. Do you?

As Mike already said, you don't actually show the code creating an index (tag), you just show the function used in the index expression. I remember this was in a lengthy recent thread, not more than a month old. It won't matter, but what matters is, that you got some wrong ideas here about how indexes work, it seems. The only reason you would put that into an extra CDX I see as possible is, that this index is larger than usual tags. Though I remember we made it some C(5) at max for each node, wasn't it in that regime? Then you're far below something even as simple as an index on a char(20) field, for example, for which you also wouldn't create an extra CDX file, so size isn't the issue. The only other reason would be to not depend on SET PROCEDURE to be configured correctly every time you use the dbf. The index then won't update automatically, though, just like IDX index files need to be open/set to update together with table data changes. So it's not a good reason.

I think besides that function, you got INDEX ON hierarchy(keyfield) TAG tagname or something like that. And, well, that's something you only do once, then this index tag is part of your table like any field is, just like you don't ALTER TABLE ADD COLUMN every time you use a table, you also don't INDEX ON anymore, once an index is established, you only use it from then on. The only added dependency with an index expression calling self-defined function is, that this function must be visible when you work in the DBF.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

(OP)
Mike,

Quote (Mike)

Koen, could you please explain how this routine is used (or link back to Griff's original post)? I can see what the code is doing, but it is not clear how that relates to the CDX.

I am referring to thread id=1804754

The purpose is to construct an order/sequence

My dbf consists of a ID which is a little bit different constructed as we know usualy: it is unique, with the following construction:
a.b.c.d.e
where a is the master and is always 1
where b is the first related record to a
where c is the first related record to b
a.s.o. and the sylables are nu numbers i indicating the sequence so 1.3.12
means 1 is the 'godfather', 3 is the third child of 1, 12 is the twelfth child of the third child of the godfather
so you can end up ID's like:
1.1
1.1.2.1
1.1.2.2
1.2.1
1.3.1
which I would like to order:
1.1.
1.2.1
1.3.1
1.1.2.1
1.1.2.2

I use Griff's procedure, which creates a Names.CDX using Names.DBF
When updating Names.dbf it errors/complains a out a CDX which should be closed, I can only close the CDX when I also close the DBF, I cannot update a closed DBF. So if I could find a way to convert/implent Griff's method into the IDX, I think I will be fine.
For completeness here is Griffs, perfectly working procedure:

CODE --> vfp

Parameters m.KeyField
Private m.KeyField,m.String,m.WordCount,I
m.WordCount = Getwordcount(m.KeyField,".")
m.String = Str(m.WordCount,2,0)
For m.I = 1 To m.WordCount
	m.String = m.String + Str(Val(Getwordnum(m.KeyField,m.I,".")),2,0)
Next
Return(M.String) 


Stay healthy,
Koen

RE: updating table with a .cdx

Griffs, procedure still just computes one hierarchy value, not an index.

You had to have something like INDEX ON HIERARCHY(keyfield) TAG tagname

And for this index to work, the Hierarchy function has to be visible. And I know, that doesn't explain an error message telling you to close a cdx, but it must have to do with this.
You open VFP, you have no SET PROCEDURE at all, you USE your table with this index, now even just an APPEND BLANK will lead to an error like "Function Hierarchy not found", or, as I know VFP then rather thinks this must be an array name "Array HIERARCHY not defined".

Well, now that you have such an index, you always have to have SET PROCEDURE TO functions.PRG with Griffs HIERARCHY function, or the DBF won't work. An index isn't just created once when you INDEX ON, it becomes an active component, it's expression is repeatedly used for new or changed data to add to the index, too.

I guess you have a corrupt index and that leads to some error like that, so reindex the dbf. And once that's rebuild never use the DBF Without the HIERARCHY function visible.

Bye, Olaf.


Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

(OP)
Olaf,

Quote (Olaf)

You rarely create a CDX, you create a tag in the main CDX of a table, you create this main CDX when you issue the first INDEX ON expression TAG tagname for a DBF or create the first index in the table designer.

And the only thing that's special about using a function in an index expression is, that SET PROCEDURE must make this function available, or usage of the CDX gets in trouble. Remember the main CDX of a table will be maintained automatically. If you update data or insert a new record all tags of the main CDX will need an update and for that to work the Hierarchy function must be visible to VFP. Besides that specialty for indexes based on user-defined functions, there is nothing special about updating a table which has a cdx besides perhaps also an fpt, you only USE the DBF, any memo like fields automatically go into the fpt and any index changes due to data changes automatically go into the CDX. For this to be possible in case an index expression uses a function, well, as already said, VFP must know where to find that to be able to call it.

However 'it does not work'. I have following code in the click on myform:

CODE --> vfp9

Set Confirm Off
*!* SelectUnbuffered('names')
*!* Index On hierarchy(parenteelid) To ParenteelIndex
SET ORDER TO HIERARCHY   && HIERARCHY(" parenteelid")
Locate
Set Confirm On 
the dbf is not sorted according to the method hierarchy, comment the line "Set Order" and uncomment the 2 lines 'Seletunbuffered... and Index on' creates a names.cdx and sets the dbf in the requested order. Fine however now I cannot update since a structural CDX must be closed.
Do you require a small test dbc with names.dbf?
Stay healthy,
Koen

RE: updating table with a .cdx

When you name your index PArenteeindex, you don't SET ORDER TO HIERARCHY.

It's not that complicated, just distinguish between function and index name and index file name, too.
And I always recommend not to name one like the other to get aware of the difference, ie also not to name an index on a simple field just like the field. Names and expressions are two different things.

And also when you create an IDX, while you use it the function must be visible to VFP. I didn't recommend and I won't recommend a separate CDX or IDX, just get used to need a SET PROCEDURE while you use your dbf with an index using Griffs function. If you store it as HIEARCHY.PRG, then CD into the folder and better also SET PATH TO it additionally, so HIERARCHY(x) can always be executed.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

Besides, just by the way, if you use an IDX instead, the command to do so then is SET ORDER TO IDXFilename, instead of SET ORDER TO tagname, if you make it a tag of the CDX.

And I still recommend that, there is no size reason and you CAN and just NEED to make that a habit or start default... you can let the hierarchy function be visible before you use your table.

And then, last not least, look what HIERARCHY("parenteelid") results in.

You want to call HIERARCHY(parenteelid), field name without quotes. The field value is your parameter, not the field name.

Bye, Olaf.


Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

Hi Koen

I think you are using the wrong command to create your index, you probably need to use this construct:

CODE

use names exclusive
select names
index on hierarchy(parenteelid) tag Parenteel 

This will create a structural index, a file called Names.cdx that can contain a number of tags, that will generally open whenever you open Names.dbf

That way you can update names as much as you like and the index will be kept up to date as well.

Regards

Griff
Keep Smileing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

RE: updating table with a .cdx

(OP)
Griff,

Than I shall have to change the structure of my DBF
I now have:



without the quotes around parenteelID in the indexexpression, VFP errors.

Stay healthy,

Koen

RE: updating table with a .cdx

Well, likely there already is a names.cdx as you would always have at least an index on the primary key of a table. But that's just a side note.
Otherwise I second Griffs way of indexing, make your index a tag of the normal structural CDX index file a DBF already has anyway.

Index usage then simply is

CODE

SET ORDER TO Parenteel 
or more verbose

CODE

SET ORDER TO TAG Parenteel 
and most verbose

CODE

SET ORDER TO TAG Parenteel OF Names.cdx 
But using the names.cdx is default, I wouldn't get that verbose.

But, but, the last but, always have HIERARCHY.PRG visible by SET DEFAULT (or CD) or by SET PATH ... ADDITIVE, at best before you even USE the dbf. It's not optional.
The only situation in which it is becoming option is when you don't change the index, ie when you only read from the DBF, but even in that case you want to sort by it, you want it to accelerate queries and locates. So just when you buy into using a user defined function as an index expression, you also have to buy into making it visible while you use the table.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

Quote:

without the quotes around parenteelID in the indexexpression, VFP errors.

Well, what error do you get?

It can't be right just because it doesn't error. Griffs function pulls out the digits separated by points and recombines them the way it's necessary. If you pass in "parenteelid", then there are neither points nor digits in that, you always get an empty string as result of that, and it is no wonder that index gets corrupt and causes all kinds of errors, as an index with all nodes being an empty string isn't working, even not when it doesn't need to be unique, just a regular index. That comapres to a c(0) field, which also will error sooner or later. So it won't perhaps error while indexing, but when using the table.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

There is an error in that screenshot Koen
the index key should be:

CODE

hierarchy(parenteelid) 

hierarchy(" parenteelid") will produce the same index value for any record because " parenteelid" is a constant not a reference to a field

The route you are using though can't 'see' hierarchy() to create the index or maintain it.

Which is why the code version works better, although if you have the code for hierarchy() in a source file you could SET PROCEDURE TO HIERARCHYCODE.PRG ADDITIVE so the function was visible in the IDE

Regards

Griff
Keep Smileing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

RE: updating table with a .cdx

Let me assume what error you get while indexing, it#s the function not being found or array not defined. Maybe it's even just that paranteelid is not the string datatype it should be. Anyway, the function HIERARCHY() must be available, visible, known where to find by VFP, while you index and later when you use the table.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

If your DBF is part of a DBC, it would be a good idea to add Griff's function to the stored procedures.

Though when that DBC is in some share then the first call to it would load the DBCs stored procs first and so a local drive location or embedded within the EXE will always be the simplest and fastest way as VFP looks inside its EXE first, then in the current directory and then elsewhere. The main advantage there is it's found. Under many conditions. I imagine a condition where it's not found, but for that, you'd really need to desperately want to hide it from being found.

You can't just have it in the code you use to index, then the indexing works, but nothing afterward. The HIERARCHY() function has to stay available to VFP, it will not become part of the DBF or CDX header nor does VFP automatically make it a stored procedure. The index expression is stored in the CDX header and will be taken and evaluated every time a new node is added to the index tree at least, but only the expression, ie the call of HIERARCHY(), not the definition itself.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

(OP)
Olaf,
I am getting the error on updating, indexing works ok.
The function hierarchy is available.
Parenteelid is a string (c 25)
Stay healthy
Koen

RE: updating table with a .cdx

If this was still at the time you called HIERARCHY(" parenteelid") I think we clarified that's not the way to call it, both me and Griff.

You have to delete that tag and create it new with the right expression HIERARCHY(parenteelid). You can't just change the expression when the CDX is corrupt, better even DELETE TAG ALL and recreate all indexes from scratch.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

(OP)
Hi,

Olaf gave me the solution with his remark that

Quote (Olaf)

the procedure should be available
. The file is located in my Progs direcotry, the Progs directory is in my path, but aparantly not visible to the dbf, why I don't know, but a simple

CODE --> vfp

Set procedure to hierarchy 
in my startup.prg before calling the dbf saved that.

error when not using quotes on the indexexpression:


the result/sorting order when using the index expression hierarchy("parenteelid") is shown on the left, the result when sorting on in shown on the right.
I am fully satisfied with the result on the left and can now update my dbf without an error about a non-structural index file to be deleted.


Thanks all for participating in this matter.
Stay healthy,
Koen

RE: updating table with a .cdx

Again, hierarchy("parenteelid") is wrong, it can't do it's job, it isn't passing in the parenteelid value but always the constant string literal "parenteelid".

Here are essential points in Griffs function and what "parenteelid" leads to:

CODE

? hierarchy("parenteelid")

Function HIERARCHY()
	Parameters m.KeyField                      && value passed in is "paranteelid"
	PRIVATE m.KeyField,m.String, m.WordCount, I
	m.Wordcount = GetWordCount(m.KeyField,".") && will be 1, no "." is present, which means the whole string counts as one word
	m.String = STR(m.WordCount,3,0) && will be "  1"
	For I = 1 to m.WordCount && loop from 1 to 1, one iteration
		m.String = m.String + STR(VAL(GetWordNum((m.KeyField,I,".")),3,0) && will be "  1  0"
	Next
	Return(m.String) 

Every index node of your index will have the value " 1 0". I wrongly said it would be empty, as I was thinking of the word count to be 0, even then the starting value of STR(m.WordCount,3,0) would be " 0". Anyway, an index on a constant result will not sort anything. In an index, where all values are equal, everything is just sorted as is, by recno, there is no sorting effect unless data already is in the order you want it by recno() anyway.

So, I'm pretty sure as your form now shows data in the order you want it, your index is on Hierarchy(parenteelid).

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

"multiple warnings occured performing...."

Well, I think this just means the CDX was so unusable at that stage, that just changing the expression in the table designer didn't help. What it would do in detail is dropping the tag as it was and creating it with the new expression. But if you just try the first step of that in a CDX that leads to the message "The nonstructural CDX file should be closed", then I think you either have two CDXes and confuse VFP or me or both or you have a situation like it is with a broken CDX that the best thing you can do is DELETE TAG ALL. The second best is to delete the CDX, but then what happens is there is a rest information about indexes in the DBC and you get in trouble with even more messages about the invalidity of the indexes or dbf or even the dbc.

Anyway, as far as it looks, you made it, I'd just double ensure the call is doing what it should do. The way you posted Griff's function has an r missing, maybe your PRG is actually differing from what you reposed here, doesn't matter much.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

(OP)
Olaf,
1) I am sorry, I can't find the type / missing R. It could be that I made a mistake making the function in retyping here in order to make it more readable since Griff originally posted in all UPPER.
Please show me where I went wrong.
2) This is interesting, you give as comment on line
m.Wordcount = GetWordCount(m.KeyField,".") && will be 1, no "." is present, which means the whole string counts as one word
however Keyfield has only 3 possible values:
1) nothing
2) "1"
3) "1."followed by a next increment - this is checked on input.
in case 1) nWordCount has 0
in case 2) nWOrdCount has 1
in case 3) nWordCount has the value of the words
Your conclusion, hierarchy("parenteelid") is wrong, it can't do it's job, it isn't passing in the parenteelid value but always the constant string literal "parenteelid", sorry I can't follow. The more the shown effect in my screenshot, does that not count to be the proof of the pudding?
Please understand me correctly I don't want to argue here, just want to be 100% sure I do understand what is going on with Griff's hierarchy function.
The error message about multiple warnings, is one of those mystic things. What I do know is that when I pass with quotes it works.
Stay healthy,
Koen

RE: updating table with a .cdx

Koen,

in the first place: Your data sorting shows it works, and I assume that's because you have a modified version of what you posted.

Where is the R missing, simply in the function name: HIERACHY (wrong spelling) vs calling HIERARCHY("parenteelid"). It's actually the first sign you use something else.

But you reject and ignore the very obvious, when you make a call HIERARCHY("parenteelid") you pass in the string "parenteelid", not the field parenteelid. You just have to execute what I posted to see this
a) it works even without a table present, that has a parenteelid field.
b) It just literally works on the string "parenteelid": pee ayy are ee, en tee ee ee el ay dee. The letters.
c) Both me and Griff pointed that out, and it's a simple fact. I don't know how you can still not see the wood for the trees. I would really like to know what's happening in you, when you still ignore something that has been pointed out 4 or five times. Just because a field name or variable with the same name exists, a string of that name is still a string of that name and doesn't turn to the variable or field value. You're pointed to the string value you pass in not working with the function as posted. You don't need to show us the composition of the values of your parenteelid field, you don't pass these values in.

There is an obvious way you overall get the sorted result and no error: You use modified code to take this passed-in field name and evaluate it and you didn't post that code. That would just be overcomplicating things, as the index expression has access to all the fields directly, passing in the field name to then evaluate it in the function code is just an extra step costing extra time. So even in that case, just mend the function to NOT need to evaluate a passed in field name, just pass in the field value and work with that, as Griff's original function does.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

How about this instead

CODE

use names exclusive
alter table names add column hiercode c(25) not null
replace all hiercode with hierarchy(parenteeid)
index on hiercode tag hiercode 

Whenever you add or mod a record, remember to

CODE

replace  hiercode with hierarchy(parenteeid) 

Regards

Griff
Keep Smileing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

RE: updating table with a .cdx

(OP)
Griff,
That is now exactly what I did not want to do! I did have this field ParenteelIndexID (grr for the very long name) which has e.g. a value of 10102111 for the parenteeeliD 1.1.2.11.1 I had a STP filling this record on every update, works fine. I could use as an index. But I have to extend my dbf with 5 more different parenteelID (for partner, for father, for mother, for stepfather and for stepmother) so I figured it would me better and easier to maintain to substitute these 5 extra fields with 5 different index expressions.
I did not manage to convert my convert my conversion into an index expression, your coding and your advise to put this as a function into my dbf index works as a charm, it is even extremely fast.
It works and I am more than happy, Ippyee!
Now I only don't understand why Olaf is complaining it cannot work and I should not place the name of the field into quotes. Microsoft seems very happy with it, and is not happy at all when I leave out the quotes.
Thanks for helping me.
Stay healthy,
Koen

RE: updating table with a .cdx

(OP)
Olaf,

your

Quote (Olaf)

when you make a call HIERARCHY("parenteelid") you pass in the string "parenteelid",

I believe you are mixing here the effect of a the function hierarchy when applied to an index.
Indeed the function itself will work without the quotes, so
tcParenteelID = '1.1.2.1.4'
? hierarchy(tcParenteelid) will return '1 1 2 1 4'
and hierarchy('tcParenteelID') will return '1 0' && you may figure out why via the debugger.
however the function as expression in the index field will return for every value of parenteelID the converted content.
There is a difference between a function and a expression containing a function.
Rest assured I did not change anything in Griff's function, I merely changed the Upper to normal and made the calling to variables more consequent to my other functions.
Stay healthy,
Koen

RE: updating table with a .cdx

Quote (Koen)

hierarchy('tcParenteelID') will return '1 0' && you may figure out why via the debugger.
I single stepped this just in my mind. And I showed this, yes. So at least we agree on that.

Quote (Koen)

There is a difference between a function and an expression containing a function.

If there is a difference between an expression you set to something, like the IIF expressions often used for grid column dynamicbackcolor, then you put the whole expression into quotes, you set dynamicbackcolor to the expression as a string, which VFP then evaluates. You quote the whole expression or nothing. But you never just set one parameter in quotes. Just all or nothing. Quoting a name would only make sense in a context where name delimiters are a thing, that's not part of VFP, though. And the situation differs when you set daynmicbackcolor in the context of the properties window, you then set the expression without quotes as the property window already knows this is a string property containing the expression, or you make use of a specialty of the property window and set it to ="expression" with a preceding = and the full expression in quotes. But then, again, it's the full expression, not just parts ot ir. And this effectively puts just the string into the property, with the potential to make it one level more complicated and use an expression that returns an expression.

None of both things is necessary in the index tab of the table designer. If you use the fields tab of the table designer, enter your field there and simply specify an index order (pick ascending or descending) directly there and then change to the index tab, you see just picking an index order you created an index, and the index expression there simply is the field name, without quotes. So no quotes necessary. Why on earth would anyone put quotes around a field name? SQL Server has that concept of name delimiters, but there it also allows spaces in names and that make such name delimiters necessary just like VFP has many string delimiters, SQL Server allows double quotes and square brackets as name delimiters, which VFP knows as string delimiters, And that's a reason people struggle when they want to specify just a string, for which SQL Server only allows single quotes. Funny, ain't it?

There are a lot of detail things to know to not become a victim of any pitfalls. But when you quote an expresion to set it as the expression and not a value resulting from the expression, then you quote the whole expression, not just parts of it or field names. You're pointing out a rule, but use another. One that would hold true for another database. You're explicitly saying it doesn't work when you don't put the name in quotes, that's a simple utter lie. It's lying I can't stand, sorry. This will work, if the function works on field values.

I dare you to do this just in code and see wha sorting you get when you browse in that order

CODE

INDEX ON hierarchy("parenteelid") TAG hierarchy2 

We're at a point you just don't want to cooperate anymore, then I'll stop here. I'll likely now stop posting anything in any forum anymore. It's just so frustrating and times are frustrating enough.

Bye, Olaf.

Olaf Doschke Software Engineering
https://www.doschke.name

RE: updating table with a .cdx

(OP)
Olaf,
That is just your own decision, which I respect but do not understand.
What gave you the impression I do not want to cooperate? I simply donot understand why you believe my Griff's coding, which shows a correct result, is not correct that's all. And please do not make simple things complicated with an example of dynamicbackcolor, we are here talking about an index expression, which is completely different. Your assumption I did change change something to Griff's excellent coding is wrong. I did not, I can assure you.
We differ in opinion all right, is that enough to get frustrated?
Stay healthy,
Koen

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close