Field File Text Translation Products Data Column Database

> Well, how many ways can I explain the same thing? But I understand if you don't understand, cause my head is in this, and yours in lumber. I also don't quite grasp a bunch of stuff on the lumber end.

ANYWAY, I will try again.

To rip apart the fields, they will essentially go through the same process as we have just put your rtf files. One field at a time. So lets say we take your Products: example. Copy the entire contents of the column (all records) into a Word file, blab,blab, try to unify and make consistent the product names using s&r and various gimmicks, perhaps use the comma as a field separator, and then spit it back through my fancy script to create the Excel file again: with the predefined field names (baby field names - the ripped apart ones created from the originally one field) on the left of the vertical line, and the newbies on the right. The newbies can all be merged into a single field Other, or individually merged or copy/pasted into the appropriate cell/field.

Or, to answer your question in summation, NO, nothing will get lost, and its doable. If you don't comprehend what I'm saying, I suggest you just trust me and you'll see the magic after I'm done with it. k

not to sound like a super-glorious moron, but there's just one one thing I need to know, and it's not about the field NAME (Grading Agency), that I get. It's about all the data inside the field. Landing to the right of the vertical line and such, yes I get it that's not my question.

this is what I am unsure about:

if we make clicky boxes for the Products: field, there is for sure going to be products that fall outside of our list. Will those automatically land in Other, or will it disappear?

For the Species: field, I can be sure to make every single appearance of every single species name exactly exact, so we can go ahead with clicky boxes for that one. But for the Products: field data, there will be product names not on the list. Also the appearance of some might not be exactly exact (capitals, spelling, hyphens) and it would just be impossible and a ridiculous waste of time to try to match it.

So if the script cannot handle, for the potential list of products made (not for the field name Products:, or you keep using grading Agency: as an example, which to me is the field name, not the data inside the field) anything outside of the list I send you, with the clicky boxes, then we are going to have to go with a text field for that one.

-Keta

---------------------------------------------

> I guess you don't need me to break down the Fields.doc file for

> you?

Don't understand. What I need is to communicate through the Wordfield.doc so I can see it all at once and properly analyse it and not through a million emails. Yes, break down the field file as concisively and logically perfect as you can. Not little tidbits here and there. I need to see things visually.

for the Notes: field, I want it to be "see also listing in Ontario Wholesalers section", meaning Wholesaler should be capital (or Reman, or Mill or whatever). I just changed them all, so don't edit that.

When you send a file back to me I'll consider it done and certainly will not want to play around with it more. I want to move onto more interesting stuff. If there are some matters which still need to be addressed, you can leave a < in the file and inform me so by email. If there is some matter you think I can take care of faster using s&r that you do not know how to, you can send it back, or just ask me how to do it. It is a useful skill which you should know how to do.

Also for Shipping: it has to be CP Rail, CN Rail, truck not CP rail, CN rail, truck

Easily taken care of with S&R. Have no plans on unnecessarily changing any of the data in the files you send back to me.

so don't edit that either. One other thing I noticed, as far as inconsistancy goes, is that - for the companies that have the same Fax: # as Phone:, sometimes it goes

That is because sometimes it said

Phone/Fax: xxxxx

which I s&red into

Phone: (and Fax) xxxx

because that is a quick and simple operation.

If you want this broken down into two fields, where each field has the exact same value, I guess that's possible. I just didn't think it was important enough. Definitely possible, but someone just has to manually go through the procedure, because the s&r would not handle something like that.

For the Excel file you already sent me, I started changing it so the Fax: # appears on its own line. I kind of prefer it that way. I'll stop with that now, so we're not changing each others' stuff back & forth (I could see that going on forever!) but just want to give you a head's up so you can take charge of making it consistent. If it needs to be

Again, try to be consistent with your terminology. In the Excel file the fields are COLUMNS, not lines (rows). There definitely IS a Fax column in each of the sheets, but in those cases where the Fax and Phone numbers are the SAME, and you want to break it up, simply copy the Phone number and paste it into the ALREADY EXISTING Fax column, and its done. Don't start creating a second Fax column when it already exists.

> for some reason then that's fine. I just prefer it the other way.

Okay, so looks like we're well on our way and that's cool. Looking forward to continuing on the form on Monday. Now that I've accomplished one field for my treeplanter database, I know how its done and I'll be able to set it up pronto for any field and any database. I'm talking about the edit function. The Just View function for your users is easy and already set up. I'll finish the conversion into Excel into Access, and by the time that is done hopefully we'll have the Fields issue finalised, so that I can commence with that. Should take roughly 8 hours of work and the dbase could be fully operational and ready to hit the big fat market!!!

----------------------------------------

> > Maybe for better clarity let's just mark each clicky field as

> > light blue or something.

> done.

okay, sending the file right back to you. Added comments inside.

> > If you want a comment next to the field then that

>

> > requires an extra field.

> used a pointy arrow <----------- explaining where I need to be able

> to fill in stuff after the list of clicky boxes.

I don't know if it matters but the Species: were all in upper case, I changed it to upper and low, like the actually entries appear in the data, just in case that was one of the super picky things that needs to be exactly exactly the same.

Yes, ee means exactlyexactly, not more, nothing less. A little trick you might not know about: if you have some text selected in Word, you can press SHIFT F3 and it toggles between different sets of capitalisation. Might have saved you a few seconds know this.

> > For the percentages we agreed it will be a text field and you'll

> just punch in the

> > percentages.

> Yes.

In which case it would be better to remove the clicky looking box thing to the left. No need to be confusing.

> > For something like Shipping we can make it a DropDown list, which

> can be set to

> > only choose one, or multiple selections (by holding down the ctrl

> or shift key). So

> > lets colour that pink. That would probably be better than clickies

> and breaking

> > Shipping up into a bunch of fields. So think of any other areas

> which would be

> > better served as a dropdown list.

> done!

As I wrote in the file, lets think of List and not Dropdown. I don't think multiple selections are possible with dropdown, but I'll look into it. If it IS possible, a Dropdown is neat because it pops out and covers a large area only when you need it, saving space on the form.

> > Go to

> > kenax.cz, Login link, my dummy account is username: kenax,

> password: kosman.

just to be super duper pooper sure, and I'm not worried but because I have been rambling the wrong words sometimes, to me "Target Language is Native" and all the stuff that looks like that counts as a clicky box.

Yes. It's always either Yes or No, or Checked or Unchecked etc. Only ONE possible choice out of TWO possible choices.

As for the pull down menu, of languages, I guess for the massive list of Species and Products, clicky boxes are just easier to use. going through a pull down list repeatedly, say if the company makes like 10 products, would be time consuming and I may as well just type it in! But you probably knew that already. Same for "For these areas, you must have at least some education or experiencing working in them.", reading through the list and multiple selecting would be a much more pain in the butt than just clicking various tick boxes.

If it's possible to select more than one using ctrl with a dropdown, you wouldn't have to go through it "repeatedly", as you said. If not possible, we can just switch to a List with a scroll on the right. This could make the final form a lot more compact. The List can have be lets say 10 rows long, with a scroll on the right, but more than a hundred selections to choose from within the list, and you can select more than one just by holding down the ctrl. You can imagine that this might be better than having a hundred clickies on the page. BUT, the advantage of the hundred clickies, even though they consume more space, is that you can see it all at once and its very visible (check mark), not possible with the List, which you actually have to scroll up and down to see what is selected (essentially checked). In this case the clickies could be better, because that will also be visisually more clear to the user, and it would be better to use the Editform also for the Viewform. Same logic, makes sense, and less work for me, cause I just Save As etc. The Viewform for the use can look pretty well identical to the Editform for you (administrator).

> hahhah, boobies! haha.

heh heh, fart

> RE: Excel file . . .

> > If a newbie field becomes increasingly common, like metric data

> once

> > you enter Europe, then I can add the new fields later.

>

> Great. Europe and Japan, both metric, both important.

Let's consume the world. sqlite should be able to handle things for a long time to come. Migration to mysql by that time shouldn't be a big problem. Especially considering, if you really do get more than 200,000 click/commands per day, I think you'll be rolling in the cash and the 200/300 bucks investment will be a pittance.

> > Concerning the Wordfield file:

I inserted Page Break, it doesn't look like anything on my screen (I am working in Text Editor, like Note Pad) hope it works when you open it. I did put a black line across to show where the break should be.

> >    - several forms, one for each category etc. Not a great pain,

> cause I can just

> > Save As the form, erase some clickies, add some new ones. More

> clear to your

> > while viewing/editing, and the same form can be used for viewing

> by the users.

> > More compact and clear rather than one massively long form. BUT,

> if it happens

> > that a company crosses into another category and you want to keep

> the company

> > as ONE record, you'll have to go to the other form to complete the

> data, since the

> > respective clicky or field is not available in the other form.

> Same record, but you

> > need two forms to complete the data.

I am not completely against one super long crazy form like your translating one. BUT, ideally I would like to see everything on one screen, EXCEPT

Products: (with all it's variations, the sizes, everything) AND Species: on a different screen together. Different form, whatever you call it.

Perhaps the popout I mentioned in the Field file might be suitable for this concept. Or the Expansion. Lets keep brainstorming.

I am not concerned about having to keep track of companies that cross into another category. I like the idea of having two forms for one record, I am used to it that way.

Still not convinced this would be the way to go, but things will become clearer once this Field file becomes clearer. As I said in the Field file, feel free to create tables for display purposes. It will be a good guideline for me, and I'll just make the webform the same. You don't actually have to line up the clickes into rows etc. and I'll deal with that. But throwing the different clicky fields into different cells of a table, now in the Field file, could be a good way to make things clear - for me and for the eventual end user. Tables are good. You can eat on them too. And place your beer on them. Very good. Over and out.

> did I say, excited??

-----------------------------------------------

sometimes it says "1x2 to 1x8" instead of 1x2, 1x3, 1x4, 1x6, 1x8" is that a problem? you are probably going to say yes. I am changing it now for this file, let me know if I need to go through that for the remaining ones. I can't believe I'm done, my wrist seized up about half an hour ago and I had to do it left-handed.

well, we're getting there, but your still missing some fundamental issues. If you want this done sooner than later, you should seriously think about this, cause I'm going to pack it in soon and if it's still not done properly than I'll just send it back to you tomorrow with questions etc. Preferably you'll get it right and I can just launch into it tomorrow and get it done.

Above, obviously the 'to' has to be converted, as I explained a million times, because the computer is not intuitive. I mean, even if the computer was the slightest bit intuitive, why would it not add 1x2.0000000001 or 1.00000001x2 etc where this word 'to' goes? The computer would simply not comprehend 'to', end of story.

Concerning the Excel file, I see your orange comments, and you are totally missing something really basic. You say "keep this". Keep what, the data or the newbie field? If the newbie field than i'd have to create a new field, which seems retarded since there are only a couple of entries. Obviously what needs to be done is the data in that newbie field needs to be MOVED to an existing field, in the correponding row, as I explained. So simply move the data to where it should belong, and go ahead and erase the column, or tell me to do it and I'll do it. For example, you said keep Certification. Yes, I understand it is a new field which we will keep.

Preservatives, keep. New field, or just throw into an existing one. Obviously an existing one. Which one though? That is why I sent it to you. Just move the darn data and erase the newbie field. When moving the data (CCA, ACQ - row 218 for the record Spray Lake Sawmills Ltd.), lets say that you decide this info should go under Products. Well just move (ctrl x) the contents into the Products column, obvously in row 218, not in some other row. You select the data WITHIN the cell, press ctrl c or x, click INTO the cell at row 218 and under the Product field, and paste it so that it is ADDED to the contents of that cell.

Honestly, to have to go and explain things on such a basic level can get really annoying. Seems to me you just whip through your work and don't put much thought into what we're doing or what i'm sending to you. What am I supposed to do with "keep". Its absolutely useless. Unless of course you really do intend to keep those newbie fields, which seems odd, considering there is very few data in it.

For All_1, newbie AverageDailyUse, use say to delete it, but why can't you just move the data into, let's say, Production or something? Think about everything carefully and hopefully I'll be able to finalise everything tomorrow.

For the 'to' case above, not sure if I'd be able to make a script replacing 'to' with the appropriate fillin. My perl programmer probably can. If there are not a lot of cases like this, probably better to just do it manually. If it looks like a lot of work, I'll ask my programmer to whip up something. All these fields which will be ripped apart into baby fields will need to be named ee exactlyexactly. It will go through the same process as the Excel sheet you are doing now, with stray misspellings etc created as newbie fields to the right of the vertical line, which can then be MOVED to left manually.

Hope you'll get it this time. At least you get a glimpse of my requirements when hiring cheapos. I've gotten into the habit of testing them now, with some tricky stuff in the past. If they just don't get it, I cant hire them. They need to understand ME. I don't cater to them. The amount of time I spend explaining simple things every time I try to assign them a task, shit, might as well have done it myself.

overandout

------------------------------------------

There can be any field you want, WHETHER it is a text field OR a clicky OR whatever, it can be anything, but it cannot be a clicky AND a text field, for example. So if you want a yes/no clicky, followed by a text field, that adds up to TWO fields. Don't see any need for confusion here.

Well, maybe a bit, after I've gone through your Field doc. I think we're getting closer to the same page, but something still seems a bit off.

For example, why do you want a text field NEXT to a clicky box? Like for additional comments about 1x3 or something? If you want a text field next to a clicky, then make it clear (blue marked box followed by black marked text). Note that the explanation of a clicky is called a "label" and is not a field. The field is the place where you input data, whether the data is in the form of a yes or no, or some text. The DESCRIPTION of the field is just a description (a label). So everywhere you want an ADDITIONAL field (lets say text), next to a clicky, ADD it, so I can see it, and colour it. It's still a bit unclear for me.

Like Shipping for example. You can have the pulldown (lets call it List, as its more accurate, since a pulldown only allows ONE selection where with a List you can have multiple selections) to select Truck etc., and all those selections within that list get thrown into a SINGLE field. But if you want to make some comments, you can just add the Rail2 as an extra field to add stray data.

So you might get:

Shipping: [truck,rail,other], Rail2: [some random gibberish text]

Cargo is not included because it was not clicked on.

Once we clear this up I think I can start playing around with the field.doc. k

--------------------------------------

okay, was launching into the field thing again when, a big duh on my part, I totally forgot that I still had to break up the fields into baby fields. I thought I was done with the conversion process but I guess not, boohoo. So I'm looking at the Fields.doc and cant see where Rough Sizes and Surfaced Sizes fit in. Under Products you got Boards and Dimension. Okay, I see now RS and SS and separate fields at the top, looks like you want to keep them as text fields, so that job is done. Phew. But breaking up the Products field looks like it could be an interesting challenge. Rolling up my sleeves now. I guess we haven't added Shake&Shingles yet? Don't see any of the fields you specified in the Fields.doc. Looking at the Species field I see you got the percentages next to the new baby field names separated by a space, so will have to ponder about that as well. Saved a copy of the Access file as I have it now because I'll definitely want to document the entire process, cause this conversion part is turning out much more time consuming than the actual database design itself. Just curious, the 1800$ quote you got, did that include all of this conversion stuff or any of it at all? Did you send the guy the original rtf files and tell him all that you wanted? I assume you didn't mention the baby breakup at the time? Not trying to increase my price or anything but just trying to gauge what I might try to charge future customers. For the Species the babies don't always have a percentage next to it, so what percentage value do you want associated with that field if there is no percentage? SInce its a text field it could be anything. I guess "Yes"? Challenge challenge challenge. I think I'll start of with Shipping. Start slow. k

-----------------------------------------

yah, I can see how I could charge in different ways. If I host it on my server I could hook up their domain to it and charge something like 10 bucks a month, and pay for my entire webhost plan. In addition to that, I recently started installing PHPList, which is a pretty powerful yet free mailing list, which can be hooked up to other scripts. It can be set to have a cap of 500 outgoing emails an hour, which is the server's recommended limit. Most servers and this one, even email providers, will block your account if you go over some daily or hourly limit, so this script is good. One good thing I like about my new php knowledge is that I can set up all these existing scripts, and modify them for my needs, where before I'd be pretty intimidated to even press the install button. I think within a year I'll have so much knowledge and scripts running, it'll be cool. I'll be a monster. k

> > Just curious, the 1800$

> > quote you got, did that include all of this conversion stuff or

> any of

> > it at all? Did you send the guy the original rtf files and tell

> him all

> > that you wanted?

I sent him samples of the original .pdf, yeah, like when I started with you. We had two phone consultations with both him and his engineer, and I explained all the yoo-haa, doo-daa, complicated stuff. They came back with the quote about a week later. It said something about a separate screen for each item or something which frightened me. I will email it to you, it's on the other computer. The major gouging action of charging for the server plus charging for the license is where I think you can make your big bucks. If you have these servers all set up, the people don't know that, they think you have to do it each time. Also, you were mentioning to me about emailing lists, there is a bit about that on the quote (or in the body of the email, I can't remember) detailing their other web services, which I bet they get paid a lot for. It sounds like the making of a database is just how they reel people in, then try to morph themselves into a one-stop-web service- stop. Which I really think you could do. It's coming in a minute!