Gossamer Forum
Home : Products : Gossamer Links : Version 1.x :

Re: Quick import prolems

Quote Reply
Re: Quick import prolems In reply to
I'll have to look at the code to see. I had a lot of trouble with imports, but I always used the "|" character without a problem. If the format of your import file is correct, you can use an SQL command directly to import it -- that often works (but it's stupid, so things have to line up just right).

As for the line:

($delim eq '\t') and ($delim = "\t");

This is a bit of perl trickery to get passed using an if-then type loop. What this one says is "If the left hand side is true, look at the right hand side, other wise, ignore the right hand side completely" (In this case this reads: If $delim is equal to the TAB character set $delim equal to the TAB character, otherwise ignore this line.)

So, if ($delim eq '\t') evaluates to "TRUE" then perl will look at ($delim = "\t") and see if it evaluates to true. But, the trick is you put something you want perl to do there -- in this case: set $delim = "\t" . Perl will only do (or see) the right hand side _if_ the left hand one is true -- pretty convoluted, but it has _limited_ usefullness in some situations.

In this case, setting $delim='\t' if $delim already == '\t' seems pretty useless.

So, that line shouldn't give you any problems, because it either evalutes to true, and sets itself back to '\t' or it evaluates to false, and is ignored.

If you are passing in a '|' you should see this assigned somewhere -- taking the $in-> delim (or something) and assiging it to $delim

-------

If you want to try to blow your brains out ... look at what happens if you do this:

($delim eq '\t') or ($delim = "\t");

This reads: If $delim is eqaul to the TAB character evaluates to TRUE go on to the next line, otherwise set $delim equal to the TAB character. Why? The right side of an "or" is only ever evaluated if the left side evaluates to False. If the left side evaluates to TRUE, the whole OR is True, so the right side is never lookd at.

Don't use these constructs unless you have a _really_ good reason to. They make debugging a real B*T*H, and logic problems -- especially nested ones (such as this inside an IF or a loop) become impossible. You almost need to write it down on a logic flow card and keep track of what is true where.

If you put a group of them together to set default values, or test for a value you need to screen out, you are cued as to what is going on. Otherwise, use at your own risk. I spent 3-4 hours trying to debug one of these 2 weeks ago.

As for the original line posted, without looking at the code (which I should do If I could) it seems a useless line, because it doesn't change anything wether it's true or false.



Subject Author Views Date
Thread Quick import prolems Martin Kjeldsen 4312 May 29, 2000, 11:02 AM
Thread Re: Quick import prolems
pugdog 4216 May 29, 2000, 12:09 PM
Thread Re: Quick import prolems
Martin Kjeldsen 4206 May 29, 2000, 12:19 PM
Thread Re: Quick import prolems
pugdog 4196 May 29, 2000, 1:08 PM
Thread Re: Quick import prolems
el noe 4157 Jun 9, 2000, 8:54 AM
Post Re: Quick import prolems
pugdog 4151 Jun 9, 2000, 11:36 PM
Thread Re: Quick import prolems
el noe 4189 Jun 10, 2000, 5:55 AM
Thread Re: Quick import prolems
pugdog 4174 Jun 11, 2000, 11:02 AM
Post Re: Quick import prolems
el noe 4150 Jun 11, 2000, 11:33 AM