Data Entry Technique for a Grocery Application

[Ray in Capetown]

Re: Data Entry Technique for a Grocery Application

That would be great Tom, to get your feedback and ideas.
BTW Another thing, the ACTUAL tables are unencumbered with this set's field rules.

Jet, the answer to all of your questions is the same - exactly as you do with any invoice form.
While the shadow is in effect you can address either the shadow tables OR the actual.

[martinwcole]

Re: Data Entry Technique for a Grocery Application

since these are "temporary" tables, in the auto exec all you have to do is copy them from the server to the workstation, and then they are local only - seems so much simpler!

[Tom Cone Jr]

Re: Data Entry Technique for a Grocery Application

Martin, can you be more specific? When you say "these temporary tables" and when you say "copy them", which tables are you referencing? Physical tables in the database, shadow tables, physical copies of physical table... my head is spinning.

[martinwcole]

Re: Data Entry Technique for a Grocery Application

hey Tom

in the autoexec, I will have a list of tables that I DO NOT want to work with shadowed - to let multiple users make changes to the tables without overwriting each other

in the autoexec, I copy the physical table from the server to the workstation, so now he can do data entry into the table on the WS, and then "append" or whatever back to the server table


here is a snippit of code



if a5.Get_Master_Path() > ""
dim temp as c
temp3="areaslocal,pagers,link,missedtherapiestoday,medsgiventoday,givenmisstoday"
for i=1 to w_count(temp3,",")
temp4=word(temp3,i,",")
mpath=a5.Get_Master_Path()
cpath=a5.get_path()
from=mpath + chr(92) + temp4 + ".dbf"
to=cpath + chr(92) + temp4 + ".dbf"
file.copy(from,to)
from=mpath + chr(92) + temp4 + ".cdx"
to=cpath + chr(92) + temp4 + ".cdx"
file.copy(from,to)
next
mpath=a5.Get_Master_Path()
cpath=a5.get_path()
from=mpath + chr(92) + "updatethisisit.bat"
to=cpath + chr(92) + "updatethisisit.bat"
file.copy(from,to)
end if

[Ray in Capetown]

Re: Data Entry Technique for a Grocery Application

Martin
You are right
That was covered earlier post #24 or post #20
There's no argument there.
BTW where were you when the primary question was asked - anyway we strayed a bit from that.
The unique user table is a spin-off issue using shadow tables, simple to implement with some different benefits.

[martinwcole]

Re: Data Entry Technique for a Grocery Application

I remember Jim Chapman writing about using shadow tables like that to open the same form with different paraameters, etc.
But in my case, just copying the table over is much simpler.

I've never done it with a set, but the approach would be the same

[JetLi]

Re: Data Entry Technique for a Grocery Application

Ray, In every user/workstation, will I create another table/tables to be shadowed? e.g. we already have bobby and billy header and line items tables, if a new terminal will be added and a new user will be created, then will I create another set of shadow tables? like say, if there are 10 users then I would have to create every name for them?

[Ray in Capetown]

Re: Data Entry Technique for a Grocery Application

Jet, for your purpose it sounds like you might try using Martin's method and the code he offered. Altogether simpler in concept - to answer your Q
You can either create the two shadow tables as each user logs in - use login name. The sample code in the help will give you the method OR you can copy two empty tables that you keep for the purpose.

Martin, as I said, for the purpose of a temp table your method is obviously the winner. But it is as narrow as that.
Wherever that temp table data gets copied to thereafter requires additional set/form/index/rules/reports infrastructure.


Please between you , Tom and the many others whom I know can write fluent code and find many ways to do things, simply for productive discussion and definitely not for challenge and hopefully practical discussion.

Think of one department, sales, having an Orange eyeglass and assembly blue and resources green - Each can hover over data through the process using their view and relationships to resources. I had started the project in a more traditional way, collecting more data migrating between tables along the way.
Here I have chosen LOWER normalization, sounds wrong, appears to work, fewer intermediate but more relevant tables. There are many less obvious advantages (in some - not all situations)
So far I have tested this positively and it promises to simplify an enterprise wide requirement that might be a year plus in development.
I am working on the POC (Ted - an acronym )

[Finian Lennon]

Re: Data Entry Technique for a Grocery Application

Hi Ray:

I thought I'd take this for a spin but I'm beached right away. No matter what I do, and I've tested on this machine in both V10 and V11, the field names from the physical table are all truncated to 10 characters in the shadow.

Have you ever seen this? I'll try to test this on another machine when I get a chance.

[Ray in Capetown]

Re: Data Entry Technique for a Grocery Application

I did actually Fin, and just truncated. I dropped the thought (thinking it was over here only) when I shared this recently. A bit remiss. (I could post as a bug tho' I use V10 ? it is very prohibitive for naming).

For Jet here is code you can use to load the temp table for each user and will make a new one where necessary - and add the record when new. prior to opening a form

'set the shadow for this user where nam is= username
hnam="i_"+left(nam,7)+"H.dbf"
lnam="i_"+left(nam,7)+"L.dbf"
if .not. (hnam$files_in_table(hnam)) 'NOT already exist
	sh=table.open("invh1") ' a proto table
	sh.DUPLICATE(a5.Get_Path()+"\\"+hnam,1) 
	sh.close()
	sl=table.open("invl1")
	sl.DUPLICATE(a5.Get_Path()+"\\"+lnam,1) 
	sl.close()
end if
InvShadowTo(hnam+"H",lnam+"L")
p=table.open(hnam)
if p.records_get()=0 'for the temp purpose I dont allow user to enter new record
	p.enter_begin()
	p.invseq=-1000
	p.enter_end()
end if
p.close()

[Ray in Capetown]

Re: Data Entry Technique for a Grocery Application

Finian
I can't figure....
In preparing a sample database for bug report, i tested it with 14 char table name and it works now
Try out the attached.. see if you can

[Finian Lennon]

Re: Data Entry Technique for a Grocery Application

Hi Ray:

I had noticed that, in your original demo, there were fields with extended field names and that was what had puzzled me.

I went back to the original V10 help (.CHM) files to see if I could get more information. There were two "Turbo Demo" links there that promised more information but unfortunately they no longer work. I have to confess that I still have only the haziest idea of how creating these tables, forms etc gives an advantage in the circumstances you and the help describe. I have a feeling that, for me at least, it will take something like a screencast showing a real-life setup before I can really see/understand what is going on.

I hadn't checked before but have now and, even with the truncated field names, the mappings to the physical table are OK and a field updated in the shadow updates the "master". It so happens that I have been looking for an easy, fast way to access a table in an external database, located on another machine in a network. I don't want to create a shadow database in this instance and this seems to be an easy and secure way to get the advantage of the shadow database without the overhead. So this has been useful for me.

[Ray in Capetown]

Re: Data Entry Technique for a Grocery Application

And there - another practical use!

I had a need and suspected for a while that shadow tables could fill it.
And it does appear to so far, with many unexpected spin-off advantages.
Not the only way to get the result but it helps simplify a complex enterprise wide application. With nil or minimal incumbent overhead on tables.

It would take some boring explanation to describe my scenario.
I am perfectly willing to but it would be an essay requiring examples and diagrams.

[Ray in Capetown]

Re: Data Entry Technique for a Grocery Application

Hi Ray,

I have ben trying to figure out your solution but being a beginner it is somewhat hard for me to implement for 3 or more users, and what to do so that once the sales have been updated on the original tables would not create duplicate receipt nos. I hope you will find time to explain how you do it as you have said in the last post of the thread that I created. Thanks very much! Jetson

Jetson, better to keep your questions on the board, not PM.
I may not understand your question, "sales updated on the original tables" - the TEMP ones? If so
At that point you would update your sales system from the temp, there issue the invoice number and print.
You would need to update common table/s from all the temp ones when complete.
Or maybe you have a different flow in your system design - do you have a system design?.
Your question, and the various offered solutions, was regarding data entry techniques.

[Ray in Capetown]

Re: Data Entry Technique for a Grocery Application

....It so happens that I have been looking for an easy, fast way to access a table in an external database, located on another machine in a network. I don't want to create a shadow database in this instance and this seems to be an easy and secure way to get the advantage of the shadow database without the overhead. So this has been useful for me.

I hadn't even thought of using it for that - I work all the time reading in an outside non-alpha system's data - I shall investigate that too.
The other system however does not keep compatible indices but the raw table are readable.