Fields Translation Database Data Record

holy duh, what a fantastic idea! Totally did not think of searching and replacing the ^p with a space or whatever if it is not before a bold. I know I was suggesting the search and replace using the formatting feature, but this did not occur to me, so it is cool that in your muddled creative mind you thought I had said this, when in fact you came up with it yourself! This should or could in fact prevent the need of hiring a cheapo, yippee. And not searching and replacing before the Mill No is an easy workaround, so tomorrow I'll screw around with what you sent me and contemplate the possibility of not resorting to hiring someone, as this removing RETURNS job was what I feared would be one of the most tedious. Or do you think there are still many steps that you deem are necessary and warrant hiring someone? Or perhaps we could work out some little tricks.

Don't forget about your decision whether or not to break up the fields further into little checkboxes. Should I try to whip you up an example in Access so that you have an idea what it would look like, to help with your decision? Maybe we could stumble on a way to search and replace those sections as well. Each one would have to be given its own field, in which the conversion might look something like this:

Before:

Sizes: 1x3, 5x7, 10x3

After:

Sizes_1x3: 1

Sizes_5x7: 1

Sizes_10x3: 1

where 1=yes in database speak, and gets converted to "Yes" during the display/form stage. A simple process when you describe formatting displays at the very end.

Now, for our "record" above (where each record in a database would refer to a particular company, or Row of a table, and the fields are the columns, and the cells are the cross between the two and holding the particular data), once I deterime which of the fields hold a "1", I would have to get fancy somehow and assign the rest of the fields in that section (of fields, for that particular category/subject) a value of zero, meaning "No".

Just to give you an idea how much extra work will be involved in to break up the fields into further fields like this. A higher initial cost for you, but one I guess you will find worth it if you foresee yourself editing this over and over in the future, meaning checkboxes would save you enough time in the long run to make this extra initial investment worthwhile. Or if eventually you will want to give access to the mills to change the information themselves, and make it easy for them. Every mill which has an email addres could easily be given access rights to change their own data. For example, each record in a database always has a numerical ID number, which starts from 1 and moves up consecutively. This is what makes a database operate quickly. When you perform a search, you say: "Give me all the ID numbers WHERE the field "Sizes" equals 1x3", "Then spit out all the fields "Mill name" which correspond to those numerical IDs".

So you could use the ID number as the mill's Username, since it is essentially secret and no one would be able to guess the other mill's username, and then fill in a new field "Password" with a lot of randomly generated gobblygoop. You could then copy these three fields (username, password, email address) and create the mass email as I mentioned, using these three fields within each custom yet computer generated email:

"Hello <Mill Name (add a fourth field)>. I am Keta the Great with the fantastic new database. If you would like to update the information yourself, feel free through this website. Your username is <username> and password is <password>. Thank you."

From what I've been learning, I don't think it would be a great deal to set this up. Did you check out what I threw up on the web? I already got the login thing going, which is basically just a separate User table. I would only have to import into that table the username, password and email fields of the entire database, once done, and then assign it special rights to modify the corresponding ID record only. Not a great deal. In which case the clicky box thing would come in handy, cause people would be more willing to update such records. Because it would be easy, and potentially fun. Secretaries can have fun and feel important pressing on clicky boxes, where willing in "1x3; 2x5" etc wouldn't be so fun, but also would be prone to errors (oops, I accidentally wrote 2x25 and didn't notice I pressed the second 2 before the 5...).

Then again, don't know how often you think it will be necessary to make such edits. If in the future you expand to include mills in the US and the rest of the world, which really wouldn't be a problem, because sqlite can certainly handle tens of thousands of records without the slightest problem, the clicky boxes would increasingly pay off because you wouldn't have to constantly piddle with and maintain the database, as they can become a headache as they grow. Eventually you can add the "application form", as I mentioned, and new mills would fill in the info themselves. You wouldn't necessarily be interested in manually punching in a Japanese mill, but they might be interested in doing that, and it would only make your dbase more valuable. Your sole job could be reduced to checking out the new "applicants" and pressing Approve or Disapprove, as the dbase head hauncho administrator.

Just throwing some ideas at you, to help with your decision. later

well at one point you said something like search for ^p^p and replace, but I think that was in reference to something else.I think you said something like,replace ^p wherever it is not before a bolded word.or, elsewhere you said we could strip out ALL the hard returns, then put one back in before a bolded word. That, of course would involve an extra step to take a hard return out from the Mill No.:unless you want to go ahead and make that a separate line entirely? Would that matter?

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

Sounds like you want to add one extra field - the email address for the rating agencies. no I meant, in the screen where people view it live on the net, for the line Grading Agency: . .let's say the OLMA, that could be a hotlink to their site. I kind of guess its not something to worry about now but would like to do in the future.

Your emails are screwing up again and it's difficult to respond to this email.

Yes, but don't you realise that this requires an additional field? : Email address of Grading Agency.

It's like the standard html code:

There are two fields here: web address (or you said email address - doesn't matter, same shit), and the name of the link.

I'm pretty sure you're going to say DUH when you see the simplicity of this. You may see only OLMA underlined on the net, but for it to be functional, a second field is implied...

If you decide that you want to break up some of the fields into clicky boxes, in essence giving birth to 30 new fields instead of one, that would definitely be more work, but basically only as much as you might imagine. the reason I'm having a hard time deciding this is because I would like an as uncomplicated actual database as possible, but then again I remember just FUMING when updating the print Directories, having to type in all that shit when it's just a selection from a static range/list. You can imagine, by the time you get half way through it's ridiculous. I'll let you know tomorrow when I do my 1) and 2) jobs I still have to do. (besides the data updating of course).

I think my other email I just wrote could help you with your decision. I totally understand what you're saying and which is why I switched to an online database for my translators, so that they can update their information themselves. And about saving myself work. In actuality, I expanded my online database to include banking details. I download that and use that data, with which I can then prepare a .csv file and upload that to my bank while logged in securely, in essence paying thousands of translators in one sweep. This is how the big corporations operate. I don't even touch my database anymore. There's also a process where the translators can upload translation samples, and I give access rights to Assessors, who then log in and grade them. Very rarely someone says they can't do something, and its usually because they're using some stupid bonehead browser. Other than that pretty well my entire operations are practically automated. So I totally understand the concept of spending more time setting something up to save myself work later. I do it every time I have to spend too much time doing something. Like dealing with translation samples was way to ridiculous, and now its basically automated.

Remember that the RETURNs need to be manually erased in all those fields, which you did not do. That seems like a lot of tedious work. let's add this to the list of boring work for whoever it's going to be, as long as you are confident they will erase only the ones they are supposed to! I know what you mean about level of intelligence and efficiency . . . if you get someone that you think can handle the other stuff but might not grasp which hard returns to erase and which to leave I can do that. It's so brainless for me, after having looked at this stuff for so many weeks.

Well, perhaps not now after your genius search and replace before Bold!

Okay, so considering it will take me about a week to find someone anyway, I'll ask you for confirmation one more time. I estimate that it would take them about 7 days to do it (total guess - but I'll certainly be on their butt to make sure they are efficient and quality and not jacking around with the price), so perhaps a two week delivery time from now. During that time I'll be working on the dbase and, once or before that is completed, it's only a matter of importing the data and adding the records. Unless of course you want the clicky box things, in which case the data needs to be reimported over the new fields, once they are broken up. Not a catastrophe. This is one of the reasons why I like to prepare it in Access beforehand - to give us both a chance to look at the results and get new ideas. yes that sounds very good. of course, if I get bogged down with other work it might be me that causes a delay. That's why I am sending you the data as I do it, so that if I can't get to it for like four days at least some work can get done. Otherwise your time frame sounds perfect.

And don't forget I've got plenty of work with developing and learning, and also with all my other and personal projects I now want to go live.

Speaking of learning, I'm almost getting more excited by the minute, because the last thing I finished off before Saturday midnight (when I force myself to stop working, because it's Sunday) is learning JAVA! I wonder how many languages I'll know. But Java could be quite good because it's supposed to be cross platform and have all sorts of juicy goodies, and be able to work with php and html and all that stuff. Basically I've been trying to figure out how to have a Delete link with the User table. Say someone's account expires, you simply press the Delete for that customer's record, and they can no longer login to view the database. It may only look like a simple <a href=..> command to you, but its not an href link but rather a command to delete the record on which the "delete" "link" was found. One dude suggested a button, which would avoid Java, but I thought a button on each row would look kind of ugly, so I decided for the link instead, which apparently requires Java. Anyway, more reading to do and perhaps I'll learn all sorts of juicy stuff that java can do. Of course, compatibility amongs browsers will have to be tested, but its all part of the fun of learning this stuff.

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

heydo,

to have clickey boxes or not have clicky boxes, that is the eternal question. It's a lot of extra work for me, but definitely doable. You were talking about sub categories, going metric, much is possible - simply a matter of extra work. At least I'll learn the stuff. For the field conversion, I was thinking that once it is all in database format, my Siberian dude should be able to split it up into separate fields, if the data is consistent. If there is some typo then I guess he could have that thrown into an "other" field, which you could then erase and manually click the correct field. If you want to go metric or anything like that, it would be advisable to create the fields now, so I don't have to do a major restructuring job later. Or otherwise to put such data into the Other field and eventually convert it if there are enough records - but you'd have to be careful about entering the data to keep it consistent, to make eventual conversion easier. I think the restructuring for the web part would be a lot more work for me than the offline access part, so it would help to have that sorted now, but it will still cost me a lot of work. Not sure how much extra I would like to charge for that. Perhaps the number of fields could be an indication. Doubling the number of fields wouldn't double the price, but at least some indication. As you learn more about all this you'd be able to approach some local dudes or whoever with a better formulated question, tell them you want a concrete price and now surprises later, to help give us an idea. I'm spending so much time piddling and diddling with error messages and learning that I'm not exactly sure how long it would take me if I knew everything. But I imagine people could charge a lot for something like this, because I imagine it's not a common skill. And as you mentioned, most companies would have to hire several people. My own programmer said he knew absolutely nothing about setting up the mysql part.

I tried the search and replace of ^p and it turns out I had to follow it by ^?, which means any character (because whether or not the ^p is bold is not always consistent), but it would not let me replace it with ^p. But I'll work around that by making a lengthy macro which replaces ^pa(not bold) with <space>a(not bold), then b, and go through the alphabet and numbers. A bit of work but cheaper than manual cheapo.

Concerning letting the mills update their records themselves, you could subject it to your moderation, perhaps lock their record individually, but that would require a lot of extra learning. At the moment I'm stuck on such small matters its almost ridiculous. I understand the concept but if things are not written perfectly it simply does not work and it takes a long time filtering through everything manually to see what's wrong. Computers are obviously zero intuitive.

One possibility is you offer them a forum or something where they can post comments themselves. I'd even suggest that. I've noticed on both my servers that you can easily install a forum for free, with moderator rights etc. against spammers. I'd like to set one up for treeplanting. The good thing about such a forum is that other people are actually "working" for you for free, adding original content to your web, which is good for seo purposes. This is why a lot of pages have a Add Comments section at the bottom, to keep them "fresh and sexy", as I like to say. Meaning that they are changed and content added occasionally. I'm getting better at everything and have even dived deep into the brain of my new automatic link exchange directory to change the script's functionality, so I could probably do the same with the installed forums.

Alternatively, you can have a little comment box which the mills can log in and add comments for their record alone. Just one field, for example, whereby the field would state that it is their own submitted comments.

Just ideas. k

> > contemplate the possibility of not resorting to hiring someone, as

> this removing

> > RETURNS job was what I feared would be one of the most tedious. Or

> do you

> > think there are still many steps that you deem are necessary and

> warrant hiring

> > someone? Or perhaps we could work out some little tricks.

um, me genius what now?? haha, see . . . maybe now you can grasp why it might seem like you have to explain things a couple of times or maybe I'm not reading properly. My experience with the 'back end' of designing a database is very limited. But my experience with data entry is pretty huge. Let's sit on this for a few days, I find myself extra busy on a Monday morning, which is unusual. Basically, if you & I split it up, each blazing through boring stuff over a couple of lazy evenings, I would rather do that. Not because I don't want to pay a cheapo dude, but because I know the consistency of work would be there. Its brutal when you get something from someone and you find out they did one tiny thing differently, which may or may not end up causing a problem.

> > Don't forget about your decision whether or not to break up the

> fields further into

> > little checkboxes.

thanks for the explanation. I realized yesterday I didn't reply to one of your emails properly: its not 1 field turning into 30, its one field turning into 30 x 4. That's why I keep going on about how the different mills have a different list of products.

> > Just to give you an idea how much extra work will be involved in

> to break up the

> > fields into further fields like this. A higher initial cost for

> you, but one I guess you

> > will find worth it if you foresee yourself editing this over and

> over in the future,

> > meaning checkboxes would save you enough time in the long run to

> make this

> > extra initial investment worthwhile.

so now that the amount of fields has multiplied, do you still think its doable? let me put it this way, as the person inputting the data it is a DREAM to have a range of boxes to select on or off. But if it makes either the design or running of the database, don't forget I want to go years and years into the future with this, cumbersome or problematic then its not worth it. I was kind of hoping there was a way to make a sub-category, you know "Products:" then within that, if its a primary mill one set of boxes is available to you, if its a panel mill a different set. But I don't think you're setting it up that way so I guess not. If its just a matter of some extra work for you I think we should do it, especially now if I can save a couple hundred bucks on cheapo dude. Agree?

> > extra initial investment worthwhile. Or if eventually you will

> want to give access

> > to the mills to change the information themselves, and make it

> easy for them.

> > Every mill which has an email addres could easily be given access

> rights to

> > change their own data.

I was thinking about this yesterday too and there is NO WAY I am getting to let these guys update their own listing if it a bunch of fields of 255 characters or more. I can just imagine the crap they would write, advertising for themselves and telling people not to go with the other guy coz he's an asshole. They would do it too, that's the kind of guys they are.

> > easy, and potentially fun. Secretaries can have fun and feel

> important pressing on

> > clicky boxes, where willing in "1x3; 2x5" etc wouldn't be so fun,

> but also would

> > be prone to errors (oops, I accidentally wrote 2x25 and didn't

> notice I pressed the

> > second 2 before the 5...).

one part of my concern, yes. not so much if I'm going it myself though.

> > Then again, don't know how often you think it will be necessary to

> make such

> > edits.

its hard to predict, things are changing a lot. but most of the changes is mills closing, not so much switching products. but who knows in the future, we're a bit screwed here and things will have to change dramatically or the industry will die.

> > If in the future you expand to include mills in the US and the

> rest of the

> > world, which really wouldn't be a problem, because sqlite can

> certainly handle

> > tens of thousands of records without the slightest problem, the

> clicky boxes would

> > increasingly pay off because you wouldn't have to constantly

> piddle with and

> > maintain the database, as they can become a headache as they

> grow.

that's good, I do think about that. the only national US lumber directory is so poorly researched I can't believe people still buy it. You mention Japan, now we are talking metric sizes (Europe too), which would instantly make some of the clicky boxes nonsensical. Maybe we should stay with the typey fields?? ow ow, decisions.

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

> > There are two fields here: web address (or you said email address

> - doesn't matter,

> > same shit), and the name of the link.

I guess what I'm trying to say is on the website, the grading agency letter (OLMA) would be a hotlink to their website. Just spewing out ideas for the future, don't bother messing with it now. Not email, I don't want to do that.

Either way it's still an extra field, but not a really big deal. How I have it set up already clicks to the mill's website, so I would only be duplicating that system. Thank goodness for duplication and the fact that the world is full of geeks who put up their scripts for free. I'm basically doing a super bandaid job, taking snippets I find on the web and trying to get it to work, learning everything in the process. Without the free snippets I think it would take me years to do all this.

> > And don't forget I've got plenty of work with developing and

> learning, and also

> > with all my other and personal projects I now want to go live.

I am sensing this week there may be a wee slowdown in progress: I have to write an extra thing this week, so most of Wednesday is already blown. I am still slogging through the mill updating so for now I will move forward with that as much as I can until next weekend (Thursday and Friday are always newsletter days).

Perhaps after you decide about the 2bornot2bclickies you could tell me which fields you want visible on the web. To protect your data from copy/paste, you could show certain key ones, as teasers or something, whereby to view the rest the person would have to click on Details, which would take them to the Individual Mill form. For them to copy data from those forms they'd have to copy/paste each field separately, so utterly tedious if you consider the number of mills that I can't imagine anyone going through that process.

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

okay, I got the login and delete function and a lot of it running smoothly, but just realised you still haven't answered my question concerning sqlite. I assume your server does not support it, and if you will want to go with mysql, I'd have to redesign it all over again, as the php to mysql is slightly different from the php to sqlite language. And no matter how only slightly the differences are, you know how finicky it all is, and it simply wouldn't work unless its exactly as it should be. I'd have to charge some premium or additional rate to go mysql, because from what I've read its more difficult. Personally I'd rather you go with sqlite, but if your server does not support it, as I fear, I guess you'd have to switch to my server or something. One possibility is to move your entire domain, either to your own account at A2 or sub into my account, which would be cheaper, or buy another domain like lumbermilldatabase.com or something and hook that up to A2, either into your own account or sub into mine. But to sub into mine I'd have to upgrade it to the advanced notch, which isn't that much more expensive, but cheaper than if you were to buy your own account. There is no limit on space or bandwidth on the more advanced version, so there would definitely be room for the both of us, and I hope to sell space to other customers in the future, who could hook up some domain there as well (unlimited).

So I'll stop working on your web thing until you give me a response. I'll definitely use all this stuff for my own projects, so I wont consider it a waste of time. The php language should be fairly similar. A new login script which works with mysql could be a whole new struggle though.

latero