Losing my margin!?

I am designing a report to output address labels (Avery 5160) and the
spacing of the data in the columns and the rows descrease as the print moves
down the page. By the final row of labels, the name line is in the row
preceeding row. I am using a list object and the margin settings are per
Avery's spec sheet.
Anyone else experience this and have a fix?
Thanks,
AndyWhat rendering output are you using? My guess is you'll have your best luck
with PDF or TIFF. HTML is pretty non-deterministic.
--
Cheers,
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"Andrew King" <acking@.cal.ameren.com> wrote in message
news:%23DfU0Z0IFHA.1176@.TK2MSFTNGP15.phx.gbl...
>I am designing a report to output address labels (Avery 5160) and the
>spacing of the data in the columns and the rows descrease as the print
>moves down the page. By the final row of labels, the name line is in the
>row preceeding row. I am using a list object and the margin settings are
>per Avery's spec sheet.
> Anyone else experience this and have a fix?
> Thanks,
> Andy
>|||I am using PDF. I have also tried to fix the size of the fields; unchecked
the "Can increase to accommodate contents".
Andy
"Jeff A. Stucker" <jeff@.mobilize.net> wrote in message
news:%23869bC3IFHA.4028@.tk2msftngp13.phx.gbl...
> What rendering output are you using? My guess is you'll have your best
> luck with PDF or TIFF. HTML is pretty non-deterministic.
> --
> Cheers,
> '(' Jeff A. Stucker
> \
> Business Intelligence
> www.criadvantage.com
> ---
> "Andrew King" <acking@.cal.ameren.com> wrote in message
> news:%23DfU0Z0IFHA.1176@.TK2MSFTNGP15.phx.gbl...
>>I am designing a report to output address labels (Avery 5160) and the
>>spacing of the data in the columns and the rows descrease as the print
>>moves down the page. By the final row of labels, the name line is in the
>>row preceeding row. I am using a list object and the margin settings are
>>per Avery's spec sheet.
>> Anyone else experience this and have a fix?
>> Thanks,
>> Andy
>|||Solved! Placed the list object inside a rectangle to fix the size of the
label and removed the right and bottom padding from the field.
"Andrew King" <acking@.cal.ameren.com> wrote in message
news:e4hyBC$IFHA.2844@.TK2MSFTNGP10.phx.gbl...
>I am using PDF. I have also tried to fix the size of the fields; unchecked
>the "Can increase to accommodate contents".
> Andy
> "Jeff A. Stucker" <jeff@.mobilize.net> wrote in message
> news:%23869bC3IFHA.4028@.tk2msftngp13.phx.gbl...
>> What rendering output are you using? My guess is you'll have your best
>> luck with PDF or TIFF. HTML is pretty non-deterministic.
>> --
>> Cheers,
>> '(' Jeff A. Stucker
>> \
>> Business Intelligence
>> www.criadvantage.com
>> ---
>> "Andrew King" <acking@.cal.ameren.com> wrote in message
>> news:%23DfU0Z0IFHA.1176@.TK2MSFTNGP15.phx.gbl...
>>I am designing a report to output address labels (Avery 5160) and the
>>spacing of the data in the columns and the rows descrease as the print
>>moves down the page. By the final row of labels, the name line is in the
>>row preceeding row. I am using a list object and the margin settings are
>>per Avery's spec sheet.
>> Anyone else experience this and have a fix?
>> Thanks,
>> Andy
>>
>

Lookup tables - one or many

So i am designing a new database that currently has several tables 'look up tables' that are used just to limit the values of columns in other tables.

my question is what is the best way to do this?

1. multiple tables - one for each set of values (ex: JobType, Position, PayGrade)
2. One large table that holds all the lookup values - has a 'Category' field to group them
3. put constraints on the columns of the tables that are 'looking up' and get rid of the lookup tables.

thanks
lucas

Lucas, well you want lookup values in a table of SOME sort, so option #3 would be out for me. Much better design to have dynamic data changes, then hard-coding constraints.

Now the real choice... probably get half of the people using one way and the other half, the other... A lot of this depends on thigns like... what is going in your lookup tables. If it's a case where you have a relatively small # of values, and they are basically all the same (an ID, Code, Name Desc), then I prefer 2 tables, the Lookup and the LookupCategory tables. Doing it that way, the main issue is that you want a constraint back to the Lookup table, so you have to either have a 2 column PK there that you FK back to, or could use triggers to maintain the "FK" constraint, ehhh.. or just key back to the single PK column and have checks in place that they are FK'ing back to one of the values for the specific Category....

But if it's a small amount of Lookup tables, or they have more attributes then ID,Code,Name,Desc... then separate tables per Lookup works ok. If you start having 50, 70, 100+ of these 5 row type tables, that gets annoying.... but a lot of people can't deal with the object-oriented stlye, so it all depends on the developers and whoever will touch the tables, to see which of those 2 options to go with.... You'll probably get more people want to use one table per lookup, than the generic approach.... Bruce

|||Right now i have about 20 small lookup tables (just one field) with around 10 records in each.

i'm the developer as well and i am just planing on using these lookup tables to populate drop down lists in the application.

i'm starting to think i should have one large lookup table with a category table; like this:

LookUp
LookUpId (pk)
Category (fk)
Value

LookUpCategory
Category (pk)

look good?
|||

In that 2 table method, I'd have the columns for ID, Code, Name and Desc.... not just the value, at least some description field, if not NAME and DESC fields. On the Category, same thing, an ID, Code, Name, Desc.... If you just have a Category, unless it's a clear varchar code, then you won't know what it is exactly, especailly if teh model grows to 30,40,50 lookups... and, since you're FKing back to this table, might be better to call it tTypeCode and tTypeCategory... then your base tables would have fields called like propertyTypeID ( as opposed to propertyLookupID)... just clearer to call them type then lookups...

Other columns you MAY want to have in the type table are a Seq# and a defaultFlag....

FKing back to the Type table, is ok like that, but you could have a phoneTypeID value be stored that is really an ID for a propertyTypeID, unless you put some check in place to enforce the selection of type ID's by category...

Bruce

|||

If you just want to validate that a column

only contains a defined set of values don't need to do things like populate drop downs the set of valid values do not change

Lookup error with code 0x80070057

Hi there,

I'm currently designing an ETL process and I'm using lookup transformations.
In one of them, I encountered an 0x80070057 error which I cannot explain.
When I'm looking at the number of rows already processed, the number is not always the same when the error occurs. This is the first strange thing. A second strange thing is the explanations given by SSIS (log):

OnError,DWHAPP1,AWW\RS9906,ODSTran1_1_1_DFT1,{002D0747-8F3E-43EF-A0EA-FE925E668ECB},{BAF1A259-7A26-49ED-B4E5-4BB9BB0BF004},08/03/2006 13:01:15,08/03/2006 13:01:15,-1073450974,0x,
The ProcessInput method on component "ODSTran1_1_1_D1_LU2" (15452) failed with error code 0x80070057. The identified component returned an error from the ProcessInput method. The error is specific to the component, but the error is fatal and will cause the Data Flow task to stop running.

I really don't get it :-(

To explain you a bit what I'm doing, I do a lookup to check if the codes used in the facts (transaction table) exist in the referential tables (dimensions). The lookup in which the problem appears is a simple select on a table.

If someone has an explanation or (better) a solution, shoot! :-)

Renaud

I reply to myself :-)

I've just tried by removing the transformation linked to the Lookup Error path and by making my transormations in another way and it seems to be ok now.

So definetely, there was a random error (because not always at the same moment. I.e. not always with the same data) linked to the Lookup Error path and the way the Lookup managed it.

Still strange to me because the error wasn't explicit at all and the solution is more a workaround than a real solution to a real problem.

Bug ? This is definetely an open question :-)

|||

When you hooked up the component to the lookup's error output did you configure the output to redirect rows on error?

Thanks,

Matt

|||

Matt David wrote:

When you hooked up the component to the lookup's error output did you configure the output to redirect rows on error?

Thanks,

Matt

Yes, I did so first of all but I had to change it to 'ignore failure' and used a workaround to avoid the random error.

The workaround works fine, so I won't waste my time on looking for the real explanation of it.

Thanks Matt :-)