SYLK: File format is not valid 

Turns out that this is a known issue with Excel as reported in this Microsoft KB article (323626).

If the first two characters in your CSV file are a capital I followed by a capital D (ID) the error occurs. Change this and the error goes away. You can either change the name of the header field or use lowercase id.

An obvious one, but easy to forget.

Essentially, in your record type properties, you can set a build sequence number. PeopleSoft builds views based on this sequence number by first building all views with sequence 0, then all views with sequence 1, then all views with sequence 2 and so on.

If you have two views: PS_XYZ_VW and PS_ABC_VW where the view PS_ABC_VW depends on the view PS_XYZ_VW because it uses PS_XYZ_VW in its view sql then set the build sequence like this:

• PS_XYZ_VW build sequence 0 (build first)
• PS_ABC_VW build sequence 1 (build second)

This will override the fact that alphabetically, PS_ABC_VW is before PS_XYZ_VW and will be built first by default (and fail).

This can mean a few different things depending on the context of the error, but in my example, I was trying to use GetRowset with the scroll context when in fact I was already in the right context.

What I mean is that I was trying this:

 &rsSSR_CART_SUS = GetRowset(Scroll.SSR_CART_SUS); 

In SSR_CART_SUS.GBL.SSR_CART_SUS.RowInit Component PeopleCode.

I'm already in the right context (in the SSR_CART_SUS scroll), so why am I trying to specify the scroll?

That's what the error is about. The correct syntax is actually:

 &rsSSR_CART_SUS = GetRowset(); 

Remember that working with Component PeopleCode is all about context - think about where your code is in relation to the structure of the component.

However, if I change the search by to type and set the drop down from user to archive - it suddenly shows up …

By the way you can use the advanced search functionality in query manager to search for an archive query by name.

This can be quite frustrating if you think there's something wrong with the way you are calling AddAttachment!

For example:

 class YourClass method YourMethod(&sInput as String) returns boolean; end-class; 

When it comes to generating the same parameters in your method and end-method declaration, simply type:

 method YourMethod Returns True; /* If you have a return */ end-method; 

Then press the green validate syntax icon on the toolbar, and it will automatically generate the parameters / return parameters for you. For example, you'll get:

 method YourMethod /+ &sInput as string +/ /+ Returns boolean +/ Returns True; end-method; 

If you add, remove, or change method parameters at a later date, again, make the appropriate changes to your method declaration (in the class area) and then press the green tick validate syntax icon and it will automatically update your method body.

This saves you a bit of typing, reduces the possibility of typos, and just makes life that little bit easier :)

The only difference I could find is that PRCSRUNCNTL_SBP2 is slightly more compact with a height of 46px vs PRCSRUNCNTL_SBP with a height of 65px. So if you want to save some extra space in the header of your run control page, go for PRCSRUNCNTL_SBP2. The fields all appear to be exactly the same.

Also don't forget to substitute the subpage record name with your own run control record name in the subpage properties.

What does this all mean? Well if you want to set a default value for a time field, use the convention 1-12A or 1-12P e.g. 1A for 1:00 am through to 12P for 12:00pm.

A physical table is required for a restartable application engine program so that the values in the state record can be stored in the database and used when the process is restarted. A derived/work record would lose information after a restart.

Why is this useful? Because it tells you whether a value is space or a null. This is something you need to be wary of in PeopleSoft because a blank entry could be either a null or space. Any good SQL Tool should let you set this up as an option in your results grid.

Note there are other ways to tell if the value in a field is a null or a space - one method is to return the length of the field (if its a space it will return 1, otherwise it will return a null - but that may depend on your database platform). Tables built through application designer usually include a constraint to indicate that the field cannot be null if it is not a date.

If you are using the MessageBox function to display a message catalog entry with bind parameters (e.g. bind variables %1, %2, %3) then it will behave as a think-time function even though you might be using a style parameter of 0 or %MsgStyle_OK. Note that the style parameter is the first parameter passed to the MessageBox function.

So only the simplest OK message box with no bind parameters doesn't behave as a think-time function.

For example, which is best?

• this-is-a-test.sql
• this_is_a_test.sql
• this is a test.sql

Well according to Jeff Atwood, looks it would seem that dashes are the best choice because they are the official substitute character for spaces in regular expressions.

The choice is always yours, but I guess if there's already an established convention, it might be worth following ….

Database Driver Error. (30,11)

It might actually just mean that you are using an expression but the text is longer than the length. E.g. by default any character expression is set to just 1 character in length, but your expression might be count(*). This is longer than 1 character hence the error.

This issue was encountered in PeopleTools 8.47.7 (from memory, but I could be wrong) - I'm not sure whether it's been fixed in later versions.

INSERT INTO PS_SOME_RECORD(EMPLID
, LONG_FIELD1
, LONG_FIELD2)
VALUES (:1
,%TextIn(:2)
,%TextIn(:3))

If the long field is not enclosed within %TextIn, then the SQL will work with long field values up to 255 characters long. Anything over that will cause a "Fatal SQL error has occurred" message to pop up - so it's hard to pick up in testing.

For example, the following SQL:

SELECT *
FROM PS_JOB JOB
WHERE EMPLID = :1
AND EMPL_RCD = :2
AND %EffdtCheck(JOB, JOB_ES, %CurrentDateIn)

expands into:

SELECT *
FROM PS_JOB JOB
WHERE EMPLID = :1
AND EMPL_RCD = :2
AND JOB_ES.EFFDT=(
SELECT MAX(EFFDT)
FROM PS_JOB JOB
WHERE JOB.EMPLID=JOB_ES.EMPLID
AND JOB.EMPL_RCD=JOB_ES.EMPL_RCD
AND JOB.EFFSEQ=JOB_ES.EFFSEQ — this shouldn't be used in EFFDT sub-query
AND JOB.EFFDT<=TO_DATE(TO_CHAR(SYSDATE,'YYYY-MM-DD'),'YYYY-MM-DD'))

As such, when retrieving the current effective row for a record with EFFSEQ as part of the key, the %EffDtCheck construct should not be used.

As Praj has already indicated, processing modes follow a bottom-up approach from Page-Fields to the component. If a component is using deferred-processing mode, pages and fields within that component can be made interactive on an individual basis (by unticking the "Allow Deferred processing" box).

However, if a component is interactive, then all pages and fields on that component are interactive as well.