Memo Field Issue

[Tom Henkel]

Re: Memo Field Issue

I'm at the point now where I'll capture the unique index at the start of this mess, then open a new instance of the cb_header table, get the appropriate recrod, then save it back with the changes. I think this will insure I have the proper record. I just don't get how the record pointer for for client "A" gets suddenly switched to client "B".

[GGandhi]

Re: Memo Field Issue

just curious..
will this happen if you get the record using fetch method and updating that record,
instead of getting the pointer to the table using table.get which gives the pointer to the record in focus?
will that avoid any confusion or not necessary?

[Tom Henkel]

Re: Memo Field Issue

Not sure, but I'm testing the 2nd instance idea now.

[DaveM]

Re: Memo Field Issue

I just don't get how the record pointer for for client "A" gets suddenly switched to client "B".

I don't think it is an issue of record pointer, but rather variables(bleed might be a good idea). 2, 3, 4 variables in the same memory space and same name all global?
If the variables were named the different, I bet the problem goes away.
sumnotes becomes sumnotes38 or 1025 or ??
DIM GlOBAL sumnotes as C = ""
In fact sumnotes may work better as a shared variable?

[Tom Henkel]

Re: Memo Field Issue

Summnotes probably doesn't need to be GLOBAL, however, I never append to sumnotes. I copy the notes field to a variable p_text, then I just build a new tbl.notes record by concatenating sumnotes and p_text.


Dave, I do believe you're right in the "Bleeding variable space" theory. I just wish I could figure out how...

[DaveM]

Re: Memo Field Issue

Tom, not sure I was testing some of this, but could not figure how to get the variable concatenated to a better choice.

var->name1+var->name2

That could segregate the memory space used by the variables.

explain: p_text+usercode(or something else)

[G Gabriel]

Re: Memo Field Issue

Torn between two lovers, feeling like a fool.....
Loving both of you is breaking all the rules.....
I am in a meeting..will elaborate in little while..

[G Gabriel]

Re: Memo Field Issue

First, let me get one thing out of the way:

Yes, the original notes from user 2 are lost. It's good we have backups.

Yes, the backup will recover the original notes, but the added notes are lost, for good..


I will get straight to the point..
You need to replace table.get() with table.open()
Few years back, I wrote a thread regarding this issue. You want to stay away from table.get() at all cost, and contrary to what people might think, table.open() is faster.

Another way around your problem, is to make sumnotes user-specific. IOW, instead of the variable name being sumnotes, the name will change dynamically based on the user.

Here is the forensics:
User 1 opens Form_1 and clicks on button that opens an xdlg in which he enters few lines of notes, and when presses OK, the script will add these notes to the existing memo.
User 2 across the river opens Form 1 on her machines, does the same thing as user one except she is on a different record, adding different lines of notes and when she presses OK, she thinks she saved her notes, only to find out, either right away if she chooses to review her notes right away, or find out some time later that these notes have nothing to do with what she wrote!
What happened??
Table.get() send a pointer to the table. It does not open a second or a third instance of the table.
So, now this table is torn between these two lovers, or who knows how many lovers..this table is becoming a brothel !!
So, if you have a variable called v_name for instance and you tell the table
tbl.change_begin()
tbl.name=v_name
tbl.change_end()

The field name is going to take the value of v_name
In this case, user 2, her notes are in sumnotes, but so is user 1's notes.
Due to timing issue, when these two users save the record at almost the same time, one of the two records is going to take the contents of sumnotes that belong to the other user.

Had you used table.open() instead, which opens a completely separate instance of the table, that would not have happened.
But to be absolutely sure that this mix up does not happen, I would make the variable name dynamic so, instead of sumnotes I would use a variable name specific to the user.
And here is how you do that:
Something like this:
txt="these are new notes"
x="tom123" 'some user ID
evaluate_template("dim v"+x+" as c")
eval("v"+x)=txt
tbl.change_begin()
tbl.memo_field=eval("v"+x)
tbl.change_end()

[DaveM]

Re: Memo Field Issue

table open vs table get in threads 9 and 11

Thanks for this
txt="these are new notes"
x="tom123" 'some user ID
evaluate_template("dim v"+x+" as c")
eval("v"+x)=txt
tbl.change_begin()
tbl.memo_field=eval("v"+x)

I still think using shadowed would eliminate the issue completely because the variables would be in the memory space on the work stations instead of the server. That makes them completely separate entities in memory. The table changes/enters would happen through the local redirection dbf files.

Let's face it, there was some reason alpha devised shadows instead of everybody working on a server. This may be it or one of them.

[Stan Mathews]

Re: Memo Field Issue

If shared memory space on a server was the issue
it would affect every script every time.
Wouldn't be occasional or limited to writing text values
to memo fields.

The benefit to shadowing is that layout definitions are stored locally and not loaded from the server each time they're opened.

[DaveM]

Re: Memo Field Issue

Stan,

The benefit to shadowing is that layout definitions are stored locally and not loaded from the server each time they're opened.

Does that not include memory space? If so why would it take way more memory for a server when the usage is direct to the server. My working number is in the 1 gig per user area although it is a bit high.

I was of the thinking that data and indexing remained on server and everything else was on the work station when shadowed. That to me would mean memory space. It would thus, be difficult to have a "bleed" of memory to another machine. Then data would be redirected via the local dbf to the parent on the server.

If shared memory space on a server was the issue
it would affect every script every time.
Wouldn't be occasional or limited to writing text values
to memo fields.

Not necessarily as some experience from the past would suggest with other than alpha. I believe it could have a lot to do with consumed pct of resources and other.
Memory bleeds existed on occasion with clipper87. They got fixed, but every now and then...
There was a time we wrote our code to stake out a section of memory "say 312kb" and ran over that number to invade another space(leak) designated for something else. Gees.. That was so long ago.

[Stan Mathews]

Re: Memo Field Issue

Does that not include memory space? If so why would it take way more memory for a server when the usage is direct to the server.

I don't think so. The only difference should be loading the layouts. The network traffic is reduced. Connecting to a server database from a local instance of Alpha should use no server memory. Opening Alpha on the server and opening the database there is a different matter. Never tried that and wouldn't.

I was of the thinking that data and indexing remained on server and everything else was on the work station when shadowed.

Network optimizing creates a local copy of the database with alias files of the actual dbf's. I haven't looked at a shadowed database for a while but I believe the cdx files are local copies. That way different users can query and reindex independently. You can easily check that by looking in the shadow database directory.

There was a time we wrote our code to stake out a section of memory "say 312kb"

Again, opening Alpha on a local machine and navigating to a server database should generate network traffic, not use any server memory. Running a copy of Alpha on the server or via TS is a different beast.

Note the documentation, not always the best but

CREATE_SHADOW() creates a shadow database (i.e. a Network Optimized database). This is the same as using the Tools > Network Optimize... command.

A Network Optimized database stores the data dictionaries (i.e. the forms, reports, scripts, etc.) on the user's local hard drive, while keeping the data on the shared network hard drive.

[DaveM]

Re: Memo Field Issue

I believe the cdx files are local copies

cdx is on the server. I believed as you and trialed it after Tom Cone said it and he was right. I just dbl checked.

by adb, and all support files being on the work station it makes sense the variables are in local memoery. Someone from alpha would have to tell me the memory and address on the work station is not the one used.

I contend(may be wrong) that ws1 and ws2 variables named the same would never be in the same space and using shadowed, would be written to dbf via the ws dbf redirects and issue would be solved.

Opening Alpha on the server and opening the database there is a different matter. Never tried that and wouldn't.

Some are doing it and I agree with you. I go a step further and make sure clients are running the runtime and for me, Shadowed.

[DaveM]

Re: Memo Field Issue

To the best of my knowledge, Tom has a very large database with many, many tables and tons of users. He is hitting issues most of us may never see due to the numbers. I also believe he is using runtime, but not shadowed. It would be great to know for sure if shadowed would cure the problems, but understand it is a very large undertaking to move that many users to shadowed.

easiest in my opinion would be to create one shadow, be sure all is working correct and then simply copy it to all machines. That is if one wished to do it. I have done this many times, but my users are generally 50 or less.

[GGandhi]

Re: Memo Field Issue

these are my observation and impression. I bought a runtime for my version 11 never used it. I use web interface, lot easier for me.

in unix world the networking is done with 'dumb' terminals and all the processing takes place in the server which spawns a new thread for each login/tty ( thus creating an unique entry) and terminal only shows what is happening out there in the server.

in windows most of the networking is done with 'smart' terminal a.k.a computers and the stationary objects are kept locally and dynamic content is still in the server there by reducing the network traffic load. and the smart terminals do the work and complete the task of showing what would have been by the server. the memory that comes with smart terminal is not because of runtime or shadowing but it is a byproduct. smart terminals come with memory.

memo fields are kept as a pointer to the table in the record already. having a separate table for memo then one to one link is no different than what alpha already has. the problem of memo field corruption happens not because it is in the same table but when memo field is open in a form for editing and navigation performed thereby confusing the pointer which record to update. if the navigation is disallowed ( as in liquorPOS using FoxPro while in editing mode ) the memo field corruption could be prevented. in this case the record pointer is expected to be correct using table.get() method when a table Is open even though the data is entered via an xdialog.(implicit in my opinion)

the problem of updating wrong record cannot be satisfactorily explained with memory leak but with misdirected pointer easily.

If i have a large database with many tables and ton of users i think i will control all aspects of data entry.
i will lockout navigation on the forms on editing mode.
i will limit my global memory usage.
i will get the record to update not implicitly but explicitly specifying which record to be updated.
this will prevent inadvertent updating wrong records since the record in question is the one being dealt with.
later when i go to the office i will test update two same records in two terminals in my liquor POS and see what happens there.

after all said and done, this in no way criticizing tom. he definitely has more experience than i. i follow and learn from many of his posts in the forum. i am only saying what i have learned so far and record corruption may be due to pointer problem than memory problem.