Offset too large for short?

HI I have a large function that works just fine until I added
this large spanning cfif statement to essentially break out of my
function if a condition didn't exist. After I added it I got the
error:
Branch Target offset too large for short
Also this function doesn't contain any cftransaction tags. Is
there anyway to increase memory or something to get rid of
this.

Branch Target offset too large for short

Similar Messages

  • Branch target offset too large for short

    Error :
    I am getting the error "Branch target offset too large for
    short" in coldfusion.
    What we are trying to do?
    We are concatenating large numbers of text. We where building
    a lengthly string. We ended up using mutliple variables and
    appending them together at the end to get it to work.
    Appending the lengthy string and writing into a file.
    Just to breif you this is a survey questions and answers we
    are generating text file with tab seperated as delimeters.
    e.g.
    The string I am using is
    <cfset Questions =
    Number#TabChar#Q1#TabChar#Q2A#TabChar#Q2B#TabChar#Q2C#TabChar#Q3A#TabChar#Q3B#TabChar#Q3C #TabChar#Q3D#TabChar#Q3E#TabChar#Q3F#TabChar#Q3G#TabChar#Q4A1#TabChar#Q4A2#TabChar#Q4A3#Ta bChar#Q4A4#TabChar#Q4A5#TabChar#Q4A6#TabChar#Q4B1#TabChar#Q4B2#TabChar#Q4B#TabChar#Q4B4#Ta bChar#Q4B5#TabChar#Q4B6#TabChar#Q4C1#TabChar#Q4C2#TabChar#Q4C3#TabChar#Q4C4#TabChar#Q4C5#T abChar#Q4C6#TabChar#Q4D1#TabChar#Q4D2#TabChar#Q4D3#TabChar#Q4D4#TabChar#Q4D5#TabChar#Q4D6# TabChar#Q4E1#TabChar#Q4E2#TabChar#Q4E3#TabChar#Q4E4#TabChar#Q4E5#TabChar#Q4E6#TabChar#Q4F1 #TabChar#Q4F2#TabChar#Q4F3#TabChar#Q4F4#TabChar#Q4F5#TabChar#Q4F6#TabChar#Q4G1#TabChar#Q4G 2#TabChar#Q4G3#TabChar#Q4G4#TabChar#Q4G5#TabChar#Q4G6#TabChar#Q4H1#TabChar#Q4H2#TabChar#Q4 H3#TabChar#Q4H4#TabChar#Q4H5#TabChar#Q4H6#TabChar#Q4I#TabChar#Q4J#TabChar#Q4K#TabChar#Q5A1 #TabChar#Q5A2#TabChar#Q5A3#TabChar#Q5A4#TabChar#Q5A5#TabChar#Q5A6#TabChar#Q5B1#TabChar#Q5B 2#TabChar#Q5B3#TabChar#Q5B4#TabChar#Q5B5#TabChar#Q5B6#TabChar#Q5C1#TabChar#Q5C2#TabChar#Q5 C3#TabChar#Q5C4#TabChar#Q5C5#TabChar#Q5C6#TabChar#Q5D1#TabChar#Q5D2#TabChar#Q5D3#TabChar#Q 5D4#TabChar#Q5D5#TabChar#Q5D6#TabChar#Q5E#TabChar#Q5F#TabChar#Q5G#TabChar#Q6A#TabChar#Q6B# TabChar#Q6C#TabChar#Q6E#TabChar#Q6F#TabChar#Q6G#TabChar#Q6H#TabChar#Q6I#TabChar#Q6J#TabCha r#Q6K#TabChar#Q7A1#TabChar#Q7A2#TabChar#Q7B1#TabChar#Q7B2#TabChar#Q7C#TabChar#Q7D#TabChar# Q8A#TabChar#Q8B#TabChar#Q8C#TabChar#Q8D#TabChar#Q8E#TabChar#Q8F#TabChar#Q8G#TabChar#Q8H#Ta bChar#Q9A1#TabChar#Q9A2#TabChar#Q9B1#TabChar#Q9B2#TabChar#Q9C1#TabChar#Q9C2#TabChar#Q9D1#T abChar#Q9D2#TabChar#Q9E1#TabChar#Q9E2#TabChar#Q9H1#TabChar#Q9H2#TabChar#Q9I1#TabChar#Q9I2# TabChar#Q9J1#TabChar#Q9J2#TabChar#Q9K1#TabChar#Q9K2#TabChar#Q9L1#TabChar#Q9L2#TabChar#Q9M# TabChar#Q9N#TabChar#Q9O#TabChar#Q9P#TabChar#Q9Q#TabChar#Q9R#TabChar#Q9S#TabChar#Q10A#TabCh ar#Q10B#TabChar#Q10C#TabChar#Q10E#TabChar#Q10F#TabChar#Q10G#TabChar#Q10H#TabChar#Q10I#TabC har#Q10J#TabChar#Q10K#TabChar#Q11A#TabChar#Q11B#TabChar#Q11C#TabChar#Q11D#TabChar#Q11E#Tab Char#Q11F#TabChar#Q11G#TabChar#Q11H#TabChar#Q11I#TabChar#Q11J#TabChar#Q11K#TabChar#Q11L#Ta bChar#Q11M#TabChar#Q11O#TabChar#Q11P#TabChar#Q11Q#TabChar#Q11R#TabChar#Q12A1#TabChar#Q12A2 #TabChar#Q12B1#TabChar#Q12B2#TabChar#Q12C1#TabChar#Q12C2#TabChar#Q12D1#TabChar#Q12D2#TabCh ar#Q12E#TabChar#Q12F#TabChar#Q12G#TabChar#Q12H#TabChar#Q12I#TabChar#Q12J#TabChar#Q12K#TabC har#Q12L#TabChar#Q13A1#TabChar#Q13A2#TabChar#Q13B1#TabChar#Q13B2#TabChar#Q13C1#TabChar#Q13 C2#TabChar#Q13D1#TabChar#Q13D2#TabChar#Q13E1#TabChar#Q13E2#TabChar#Q13H1#TabChar#Q13H2#Tab Char#Q13I1#TabChar#Q13I2#TabChar#Q13J1#TabChar#Q13J2#TabChar#Q13K1#TabChar#Q13K2#TabChar#Q 13L#TabChar#Q13M#TabChar#Q13N#TabChar#Q14A1#TabChar#Q14A2#TabChar#Q14B1#TabChar#Q14B2#TabC har#Q14C1#TabChar#Q14C2#TabChar#Q14D#TabChar#Q14E#TabChar#Q14F#TabChar#Q14G#TabChar#Q14H#T abChar#Q15A#TabChar#Q15B#TabChar#Q15C#TabChar#Q15D#TabChar#Q15E#TabChar#Q15F#TabChar#Q15G# TabChar#Q15H#TabChar#Q16A#TabChar#Q16B#TabChar#Q16C#TabChar#Q16D#TabChar#Q16E#TabChar#Q16F #TabChar#Q17A1#TabChar#Q17A2#TabChar#Q17A3#TabChar#Q17B#TabChar#Q17C#TabChar#Q17D#TabChar# Q17E#TabChar#Q17F#TabChar#Q17G#TabChar#Q17H#TabChar#Q18A1#TabChar#Q18A2#TabChar#Q18B1#TabC har#Q18B2#TabChar#Q18C1#TabChar#Q18C2#TabChar#Q18D1#TabChar#Q18D2#TabChar#Q18E1#TabChar#Q1 8E2#TabChar#Q18H1#TabChar#Q18H2#TabChar#Q18I1#TabChar#Q18I2#TabChar#Q18J1#TabChar#Q18J2#Ta bChar#Q18K1#TabChar#Q18K2#TabChar#Q18L1#TabChar#Q18L2#TabChar#Q18M1#TabChar#Q18M2#TabChar# Q18N1#TabChar#Q18N2#TabChar#Q18O1#TabChar#Q18O2#TabChar#Q18P1#TabChar#Q18P2#TabChar#Q18Q1# TabChar#Q18Q2#TabChar#Q18R1#TabChar#Q18R2#TabChar#Q18S1#TabChar#Q18S2#TabChar#Q18T1#TabCha r#Q18T2#TabChar#Q18U1#TabChar#Q18U2#TabChar#Q18V1#TabChar#Q18V2#TabChar#Q18W1#TabChar#Q18W 2#TabChar#Q18X1#TabChar#Q18X2#TabChar#Q18Y1#TabChar#Q18Y2#TabChar#Q18Z1#TabChar#Q18Z2#TabC har#Q18A11#TabChar#Q18A12#TabChar#Q18B11#TabChar#Q18B12#TabChar#Q18C11#TabChar#Q18C12#TabC har#Q18D11#TabChar#Q18D12#TabChar#Q18E11#TabChar#Q18E12#TabChar#Q18H11#TabChar#Q18H12#TabC har#Q18I11#TabChar#Q18I12#TabChar#Q18J11#TabChar#Q18J12#TabChar#Q18K11#TabChar#Q18K12#TabC har#Q18L11#TabChar#Q18L1Z#TabChar#Q18M11#TabChar#Q18M12#TabChar#Q18N11#TabChar#Q18N12#TabC har#Q18O11#TabChar#Q18O12#TabChar#Q18P11#TabChar#Q18P12#TabChar#Q18Q11#TabChar#Q18Q12#TabC har#Q18R11#TabChar#Q18R12#TabChar#Q18S11#TabChar#Q18S12#TabChar#Q18T11#TabChar#Q18T12#TabC har#Q18U11#TabChar#Q18U12#TabChar#Q18V11#TabChar#Q18V12#TabChar#Q18W11#TabChar#Q18W12#TabC har#Q18X11#TabChar#Q18X12#TabChar#Q18Y11#TabChar#Q18Y12#TabChar#Q18Z11#TabChar#Q18Z12#TabC har#Q18A21#TabChar#Q19A#TabChar#Q19B#TabChar#Q19C>
    <cfset answers=#Q1#q2#....>
    Can anyone please help me out?

    Error :
    I am getting the error "Branch target offset too large for
    short" in coldfusion.
    What we are trying to do?
    We are concatenating large numbers of text. We where building
    a lengthly string. We ended up using mutliple variables and
    appending them together at the end to get it to work.
    Appending the lengthy string and writing into a file.
    Just to breif you this is a survey questions and answers we
    are generating text file with tab seperated as delimeters.
    e.g.
    The string I am using is
    <cfset Questions =
    Number#TabChar#Q1#TabChar#Q2A#TabChar#Q2B#TabChar#Q2C#TabChar#Q3A#TabChar#Q3B#TabChar#Q3C #TabChar#Q3D#TabChar#Q3E#TabChar#Q3F#TabChar#Q3G#TabChar#Q4A1#TabChar#Q4A2#TabChar#Q4A3#Ta bChar#Q4A4#TabChar#Q4A5#TabChar#Q4A6#TabChar#Q4B1#TabChar#Q4B2#TabChar#Q4B#TabChar#Q4B4#Ta bChar#Q4B5#TabChar#Q4B6#TabChar#Q4C1#TabChar#Q4C2#TabChar#Q4C3#TabChar#Q4C4#TabChar#Q4C5#T abChar#Q4C6#TabChar#Q4D1#TabChar#Q4D2#TabChar#Q4D3#TabChar#Q4D4#TabChar#Q4D5#TabChar#Q4D6# TabChar#Q4E1#TabChar#Q4E2#TabChar#Q4E3#TabChar#Q4E4#TabChar#Q4E5#TabChar#Q4E6#TabChar#Q4F1 #TabChar#Q4F2#TabChar#Q4F3#TabChar#Q4F4#TabChar#Q4F5#TabChar#Q4F6#TabChar#Q4G1#TabChar#Q4G 2#TabChar#Q4G3#TabChar#Q4G4#TabChar#Q4G5#TabChar#Q4G6#TabChar#Q4H1#TabChar#Q4H2#TabChar#Q4 H3#TabChar#Q4H4#TabChar#Q4H5#TabChar#Q4H6#TabChar#Q4I#TabChar#Q4J#TabChar#Q4K#TabChar#Q5A1 #TabChar#Q5A2#TabChar#Q5A3#TabChar#Q5A4#TabChar#Q5A5#TabChar#Q5A6#TabChar#Q5B1#TabChar#Q5B 2#TabChar#Q5B3#TabChar#Q5B4#TabChar#Q5B5#TabChar#Q5B6#TabChar#Q5C1#TabChar#Q5C2#TabChar#Q5 C3#TabChar#Q5C4#TabChar#Q5C5#TabChar#Q5C6#TabChar#Q5D1#TabChar#Q5D2#TabChar#Q5D3#TabChar#Q 5D4#TabChar#Q5D5#TabChar#Q5D6#TabChar#Q5E#TabChar#Q5F#TabChar#Q5G#TabChar#Q6A#TabChar#Q6B# TabChar#Q6C#TabChar#Q6E#TabChar#Q6F#TabChar#Q6G#TabChar#Q6H#TabChar#Q6I#TabChar#Q6J#TabCha r#Q6K#TabChar#Q7A1#TabChar#Q7A2#TabChar#Q7B1#TabChar#Q7B2#TabChar#Q7C#TabChar#Q7D#TabChar# Q8A#TabChar#Q8B#TabChar#Q8C#TabChar#Q8D#TabChar#Q8E#TabChar#Q8F#TabChar#Q8G#TabChar#Q8H#Ta bChar#Q9A1#TabChar#Q9A2#TabChar#Q9B1#TabChar#Q9B2#TabChar#Q9C1#TabChar#Q9C2#TabChar#Q9D1#T abChar#Q9D2#TabChar#Q9E1#TabChar#Q9E2#TabChar#Q9H1#TabChar#Q9H2#TabChar#Q9I1#TabChar#Q9I2# TabChar#Q9J1#TabChar#Q9J2#TabChar#Q9K1#TabChar#Q9K2#TabChar#Q9L1#TabChar#Q9L2#TabChar#Q9M# TabChar#Q9N#TabChar#Q9O#TabChar#Q9P#TabChar#Q9Q#TabChar#Q9R#TabChar#Q9S#TabChar#Q10A#TabCh ar#Q10B#TabChar#Q10C#TabChar#Q10E#TabChar#Q10F#TabChar#Q10G#TabChar#Q10H#TabChar#Q10I#TabC har#Q10J#TabChar#Q10K#TabChar#Q11A#TabChar#Q11B#TabChar#Q11C#TabChar#Q11D#TabChar#Q11E#Tab Char#Q11F#TabChar#Q11G#TabChar#Q11H#TabChar#Q11I#TabChar#Q11J#TabChar#Q11K#TabChar#Q11L#Ta bChar#Q11M#TabChar#Q11O#TabChar#Q11P#TabChar#Q11Q#TabChar#Q11R#TabChar#Q12A1#TabChar#Q12A2 #TabChar#Q12B1#TabChar#Q12B2#TabChar#Q12C1#TabChar#Q12C2#TabChar#Q12D1#TabChar#Q12D2#TabCh ar#Q12E#TabChar#Q12F#TabChar#Q12G#TabChar#Q12H#TabChar#Q12I#TabChar#Q12J#TabChar#Q12K#TabC har#Q12L#TabChar#Q13A1#TabChar#Q13A2#TabChar#Q13B1#TabChar#Q13B2#TabChar#Q13C1#TabChar#Q13 C2#TabChar#Q13D1#TabChar#Q13D2#TabChar#Q13E1#TabChar#Q13E2#TabChar#Q13H1#TabChar#Q13H2#Tab Char#Q13I1#TabChar#Q13I2#TabChar#Q13J1#TabChar#Q13J2#TabChar#Q13K1#TabChar#Q13K2#TabChar#Q 13L#TabChar#Q13M#TabChar#Q13N#TabChar#Q14A1#TabChar#Q14A2#TabChar#Q14B1#TabChar#Q14B2#TabC har#Q14C1#TabChar#Q14C2#TabChar#Q14D#TabChar#Q14E#TabChar#Q14F#TabChar#Q14G#TabChar#Q14H#T abChar#Q15A#TabChar#Q15B#TabChar#Q15C#TabChar#Q15D#TabChar#Q15E#TabChar#Q15F#TabChar#Q15G# TabChar#Q15H#TabChar#Q16A#TabChar#Q16B#TabChar#Q16C#TabChar#Q16D#TabChar#Q16E#TabChar#Q16F #TabChar#Q17A1#TabChar#Q17A2#TabChar#Q17A3#TabChar#Q17B#TabChar#Q17C#TabChar#Q17D#TabChar# Q17E#TabChar#Q17F#TabChar#Q17G#TabChar#Q17H#TabChar#Q18A1#TabChar#Q18A2#TabChar#Q18B1#TabC har#Q18B2#TabChar#Q18C1#TabChar#Q18C2#TabChar#Q18D1#TabChar#Q18D2#TabChar#Q18E1#TabChar#Q1 8E2#TabChar#Q18H1#TabChar#Q18H2#TabChar#Q18I1#TabChar#Q18I2#TabChar#Q18J1#TabChar#Q18J2#Ta bChar#Q18K1#TabChar#Q18K2#TabChar#Q18L1#TabChar#Q18L2#TabChar#Q18M1#TabChar#Q18M2#TabChar# Q18N1#TabChar#Q18N2#TabChar#Q18O1#TabChar#Q18O2#TabChar#Q18P1#TabChar#Q18P2#TabChar#Q18Q1# TabChar#Q18Q2#TabChar#Q18R1#TabChar#Q18R2#TabChar#Q18S1#TabChar#Q18S2#TabChar#Q18T1#TabCha r#Q18T2#TabChar#Q18U1#TabChar#Q18U2#TabChar#Q18V1#TabChar#Q18V2#TabChar#Q18W1#TabChar#Q18W 2#TabChar#Q18X1#TabChar#Q18X2#TabChar#Q18Y1#TabChar#Q18Y2#TabChar#Q18Z1#TabChar#Q18Z2#TabC har#Q18A11#TabChar#Q18A12#TabChar#Q18B11#TabChar#Q18B12#TabChar#Q18C11#TabChar#Q18C12#TabC har#Q18D11#TabChar#Q18D12#TabChar#Q18E11#TabChar#Q18E12#TabChar#Q18H11#TabChar#Q18H12#TabC har#Q18I11#TabChar#Q18I12#TabChar#Q18J11#TabChar#Q18J12#TabChar#Q18K11#TabChar#Q18K12#TabC har#Q18L11#TabChar#Q18L1Z#TabChar#Q18M11#TabChar#Q18M12#TabChar#Q18N11#TabChar#Q18N12#TabC har#Q18O11#TabChar#Q18O12#TabChar#Q18P11#TabChar#Q18P12#TabChar#Q18Q11#TabChar#Q18Q12#TabC har#Q18R11#TabChar#Q18R12#TabChar#Q18S11#TabChar#Q18S12#TabChar#Q18T11#TabChar#Q18T12#TabC har#Q18U11#TabChar#Q18U12#TabChar#Q18V11#TabChar#Q18V12#TabChar#Q18W11#TabChar#Q18W12#TabC har#Q18X11#TabChar#Q18X12#TabChar#Q18Y11#TabChar#Q18Y12#TabChar#Q18Z11#TabChar#Q18Z12#TabC har#Q18A21#TabChar#Q19A#TabChar#Q19B#TabChar#Q19C>
    <cfset answers=#Q1#q2#....>
    Can anyone please help me out?

  • Branch target offset too large for short - using CFThread

    I am just starting to get into using CFThread.  I have a process I am working on to allow clients to order background reports on multiple applicants simultaneously.  I am doing this using CFThread.  Through some trial and error I discovered that I needed to var scope the variables that are used in the CFC's that do the bulk of the report processing.  As soon as I did that I started getting the error "                                                                                                                                                      Branch target offset too large for short". Everything I have read on this error basically says I have too much code in the CFC which doesn't make sense as I am using this CFC in several other places in the site without error.  The problem only occured after var scoping my variables in the CFC and them sticking that CFC inside a CFTHread tag.
    Has only one seen anything like this before?
    Thanks

    Haven't seen it, no.
    Can you revert to your un-VARed code, and then re-VAR the variables one by one, retesting between each, and see if a specific one gives you the error?
    I don't know what this might tell you, but it might help focus where to look.
    NB: you should be VARing your variables within functions as a matter of course, not simply in situations in which the code is being called via <cfthread>.
    Adam

  • Cannot decrypt RSA encrypted text : due to : input too large for RSA cipher

    Hi,
    I am in a fix trying to decrypt this RSA encrypted String ... plzz help
    I have the encrypted text as a String.
    This is what I do to decrypt it using the Private key
    - Determine the block size of the Cipher object
    - Get the array of bytes from the String
    - Find out how many block sized partitions I have in the array
    - Encrypt the exact block sized partitions using update() method
    - Ok, now its easy to find out how many bytes remain (using % operator)
    - If the remaining bytes is 0 then simply call the 'doFinal()'
    i.e. the one which returns an array of bytes and takes no args
    - If the remaining bytes is not zero then call the
    'doFinal(byte [] input, int offset, in inputLen)' method for the
    bytes which actually remained
    However, this doesnt work. This is making me go really crazy.
    Can anyone point out whats wrong ? Plzz
    Here is the (childish) code
    Cipher rsaDecipher = null;
    //The initialization stuff for rsaDecipher
    //The rsaDecipher Cipher is using 256 bit keys
    //I havent specified anything regarding padding
    //And, I am using BouncyCastle
    String encryptedString;
    // read in the string from the network
    // this string is encrypted using an RSA public key generated earlier
    // I have to decrypt this string using the corresponding Private key
    byte [] input = encryptedString.getBytes();
    int blockSize = rsaDecipher.getBlockSize();
    int outputSize = rsaDecipher.getOutputSize(blockSize);
    byte [] output = new byte[outputSize];
    int numBlockSizedPartitions = input.length / blockSize;
    int numRemainingBytes = input.length % blockSize;
    boolean hasRemainingBytes = false;
    if (numRemainingBytes > 0)
      hasRemainingBytes = true;
    int offset = 0;
    int inputLen = blockSize;
    StringBuffer buf = new StringBuffer();
    for (int i = 0; i < numBlockSizedPartitions; i++) {
      output = rsaDecipher.update(input, offset, blockSize);
      offset += blockSize;
      buf.append(new String(output));
    if (hasRemainingBytes) {
      //This is excatly where I get the "input too large for RSA cipher"
      //Which is suffixed with ArrayIndexOutofBounds
      output = rsaDecipher.doFinal(input,offset,numRemainingBytes);
    } else {
      output = rsaDecipher.doFinal();
    buf.append(new String(output));
    //After having reached till here, will it be wrong if I assumed that I
    //have the properly decrypted string ???

    Hi,
    I am in a fix trying to decrypt this RSA encrypted
    String ... plzz helpYou're already broken at this point.
    Repeat after me: ciphertext CANNOT be safely represented as a String. Strings have internal structure - if you hand ciphertext to the new String(byte[]) constructor, it will eat your ciphertext and leave you with garbage. Said garbage will fail to decrypt in a variety of puzzling fashions.
    If you want to transmit ciphertext as a String, you need to use something like Base64 to encode the raw bytes. Then, on the receiving side, you must Base64-DEcode back into bytes, and then decrypt the resulting byte[].
    Second - using RSA as a general-purpose cipher is a bad idea. Don't do that. It's slow (on the order of 100x slower than the slowest symmetric cipher). It has a HUGE block size (governed by the keysize). And it's subject to attack if used as a stream-cipher (IIRC - I can no longer find the reference for that, so take it with a grain of salt...) Standard practice is to use RSA only to encrypt a generated key for some symmetric algorithm (like, say, AES), and use that key as a session-key.
    At any rate - the code you posted is broken before you get to this line:byte [] input = encryptedString.getBytes();Go back to the encrypting and and make it stop treating your ciphertext as a String.
    Grant

  • Why is Encore 5.1 AUTO mode building files just a bit too large for DVDs?

    I've been doing the same videos for a few years using Encore 1.5 and more recently Encore 5.1 (with Premiere 5.5).  The videos are typically football games with short 2-25 secs of motion menus.  If I put two games per DVD, the total running time has been up to 2 hours total per game.  I've made dozens of these with Premier writing AVI files (standard 720x480 vide) and writing in Encore 1.5 using auto settings.  With Premiere CS4 I started using the dynamic link to Encore CS4 and still ran beautiful DVDs on auto transcoding.
    Now, when using the same standard video files in Premiers 5.5, and using dynamic link to Encore 5.1, on auto transcode settings, the image files or transcode files (depending on how I order the build) keep coming out 150 - 300 MBs too large for the DVDs (typically Tayo-Yuden or Verbatim burning to Plextor/Pioneer drives). (Windows-7-X64 Intel D975XBX2 MB.)
    To see if I was going nuts, I recently saved a job as two AVI files (same length as the sequences sent through dynamic link to Encore CS5.1) and did the same DVD setup in Encore CS4 but importing the AVI files as timelines.  The chapter points didn't convert for Encore CS4 so I had to install manually. The end result, though, was a DVD image that worked fine.
    So I then went to the Encore CS5 build window and set the DVD size to manual, dropping down from 4.7GBs to 4.25.  The result fit, but then left too much free space (though the vids still looked OK). 
    I know by other discussions that others are having issues with Encore CS5.1 - or maybe it is related to Premiere 5.5 sequences.  Recently burned a set with 22 secs motion menu and 1.4 hours of video and had no problems on auto.  This leads me to believe either that Encore is underestimating the transcode sizes or there is a problem with writing DVDs at or near two hours in length. 
    Anybody have answers, suggestions?
    Thanks,
    Doug A

    Thanks, Giorgio.
    I do you imgburn quite a bit and even the new version 2.5.6.0 which allows for truncating and overburning wouldn't write to either the Plextor burners or the Pioneer 205 (Blu-Ray in DVD mode).
    I just ran another image build setting the disc size (for the burn) at 4.5GBs rather than the automatic 4.7GBs.  This helped and gave me a final image size of 4.33GBs - still not large enough to maximize the disc and the compressed code for better quality, but in this case, a tradeoff for just getting the job done.
    I hope Adobe updates a fix for this problem, if indeed, it turns out to be a bug.  Also, while I'm on the the bandwagon, the motion previews in Encore 5.1 do seem to preview in very low res.  I'll need to check to see if there is a setting for this, but I've not experienced it before 5.1.
    Regards,
    Doug A

  • Value too large for column in sqlscrips

    Hi
    i getting this error pls give any idea on this
    DECLARE
    ERROR at line 1:
    ORA-12899: value too large for column "CUSTOM"."CUAR_OPEN_ORDERS"."CUSTOMER_NAME" (actual: 43, maximum: 35)
    ORA-06512: at line 423

    HI
    It is due to short  length  defined  for a variable , but  the passing values is higher  in lenght.
    Just  increase  the the length value in declare  statement.
    It is better  always give  possible maximum values while defining  variable length

  • JSPX: code too large for try statement try

    I'm migrating an application from Tomcat 5 to OC4J 10.1.3.2 and I'm getting the following error in a JSPX file.
    8770
    [jsp src:line #:931]
    code too large for try statement try { 
    This isn't an issue in Tomcat because of the way jasper creates the .java file. OC4J creates one really long _jspService method.  Is there anything I can do short of rewriting the page to fix this?  Let me know if further information is required.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    I have created bug 6152265 to track this.

  • Service replication Dump SYSFAIL Invalid subfield access: Offset too large.

    Hello,
    I am working with SRM 7.0, Backend: SAP ERP 6.0 EHP4
    My problem is that I have replicated the SERVICE MASTER from R/3.But in
    tcode SMQ1 for Queue: R3AI_SERVICE_MASTER the system shows the following
    error message:SYSFAIL Invalid subfield access: Offset too large.
    In SRM the Range are SRM external match with R/3 internal.
    I have already replicated OK the following:
    DNL_CUST_PROD0
    DNL_CUST_PROD1
    DNL_CUST_SRVMAS
    Could anybody please advise, it would be well appreciated.
    Kind regards,

    Hello,
    the problem was the table CRMSUBTAB for the Service line had a field ticked as inactive.

  • Why is TM telling me backup is too large for disk?

    Since upgrading to SL, I get this error message when I attempt to run TM back ups:
    _+"This back up is too large for the backup disc. The backup requires 123.28gb but only 66.44gb are available."+_
    My HD is currently holding 174gb of used space. The LaCie backup drive is 250gb and there is nothing else on this disk.
    I thought the culprit might be some movie files i recently imported. I deleted all of those files from all TM backups but that didn't work. Then I tried to erase the backup drive and start over using Disk Utility. That didn't work either. I read on another post to dump the plist and restart the computer, then redesignate the backup drive. Still didn't work.
    Any suggestions out there on what is happening and how to fix?

    Jaydon wrote:
    Not sure how i would tell if it's "scratch" or not.
    Sorry, that's a common term for a "working" disk/partition/folder that is temporary and not to be saved.
    Sorry for the fire drill. I thought a 250gb drive would logically be enough for 175gb worth of data.
    Yes, Apple doesn't make that very clear.
    I'll definitely look into a larger drive. Any recs on reliable brand?
    Most any drive will work with Macs, and Time Machine.
    If you think you ever might want to put a "bootable clone" on it, be sure it's a bootable drive. Most Intel Macs can boot from F/W or USB. But some Western Digitals won't boot a Mac. Their list of which ones should and +should not+ boot: http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/stdadp.php?pfaqid=1787. But note the disclaimer that they don't support it +*at all.+*.
    In addition, many of them have a built-in sleep mode that cannot be disabled, and sometimes interferes with Time Machine backups: http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/stdadp.php?pfaqid=1376
    Depending on what ports you have, FireWire 800 is by far the fastest; FireWire 400 next, and USB slowest (F/W 400 and USB 2.0 are rated about the same for short bursts, but F/W is faster for sustained transfers. Also, your Mac's CPU has to do more of the work with USB, so actual throughput is usually less).
    Many folks think USB is less reliable than FireWire. If you do get USB, be sure to connect it to a port on your Mac, not a keyboard (that may be only USB 1.0). Try to avoid hubs, too.
    If you're using USB, it's usually best to get a drive with it's own power supply, as taking power from your Mac can be a marginal proposition. Portable FireWire drives without separate power supplies don't seem to have this problem.
    Take any advice for or against particular makes or models with a grain of salt: all makers (of just about anything) can have a "run" of bad components, or a relatively few early failures. Plus, by the time any really good trends are noted, the model has probably been revised or replaced anyway!
    Marking solved....thanks again
    Great, and thanks for the star!

  • Backup too large for volume

    I have 2 macbook pro's (120GB & 160GB) backing up to a 500GB TM.
    both were backing up just fine, however in the past month the 160GB
    macbook pro keeps getting this message.....
    "backup too large for volume?"
    and subsequently the backup fails?
    the size of the backup is less than the free space on the TM drive...
    any help?

    dave,
    *_Incremental Backups Seem Too Large!_*
    Open the Time Machine Prefs on the Mac in question. How much space does it report you have "Available"? When a backup is initiated how much space does it report you need?
    Now, consider the following, it might give you some ideas:
    Time Machine performs backups at the file level. If a single bit in a large file is changed, the WHOLE file is backed up again. This is a problem for programs that save data to monolithic virtual disk files that are modified frequently. These include Parallels, VMware Fusion, Aperture vaults, or the databases that Entourage and Thunderbird create. These should be excluded from backup using the Time Machine Preference Exclusion list. You will, however, need to backup these files manually to another external disk.
    One poster observed regarding Photoshop: “If you find yourself working with large files, you may discover that TM is suddenly backing up your scratch disk's temp files. This is useless, find out how to exclude these (I'm not actually sure here). Alternatively, turn off TM whilst you work in Photoshop.” [http://discussions.apple.com/thread.jspa?threadID=1209412]
    If you do a lot of movie editing, unless these files are excluded, expect Time Machine to treat revised versions of a single movie as entirely new files.
    If you frequently download software or video files that you only expect to keep for a short time, consider excluding the folder these are stored in from Time Machine backups.
    If you have recently created a new disk image or burned a DVD, Time Machine will target these files for backup unless they are deleted or excluded from backup.
    *Events-Based Backups*
    Time Machine does not compare file for file to see if changes have been made. If it had to rescan every file on your drive before each backup, it would not be able to perform backups as often as it does. Rather, it looks for EVENTS (fseventsd) that take place involving your files and folders. Moving/copying/deleting/saving files and folders creates events that Time Machine looks for. [http://arstechnica.com/reviews/os/mac-os-x-10-5.ars/14]
    Installing new software, upgrading existing software, or updating Mac OS X system software can create major changes in the structure of your directories. Every one of these changes is recorded by the OS as an event. Time Machine will backup every file that has an event associated with it since the installation.
    Files or folders that are simply moved or renamed are counted as NEW files or folders. If you rename any file or folder, Time Machine will back up the ENTIRE file or folder again no matter how big or small it is.
    George Schreyer describes this behavior: “If you should want to do some massive rearrangement of your disk, Time Machine will interpret the rearranged files as new files and back them up again in their new locations. Just renaming a folder will cause this to happen. This is OK if you've got lots of room on your backup disk. Eventually, Time Machine will thin those backups and the space consumed will be recovered. However, if you really want recover the space in the backup volume immediately, you can. To do this, bring a Finder window to the front and then click the Time Machine icon on the dock. This will activate the Time Machine user interface. Navigate back in time to where the old stuff exists and select it. Then pull down the "action" menu (the gear thing) and select "delete all backups" and the older stuff vanishes.” (http://www.girr.org/mac_stuff/backups.html)
    *TechTool Pro Directory Protection*
    This disk utility feature creates backup copies of your system directories. Obviously these directories are changing all the time. So, depending on how it is configured, these backup files will be changing as well which is interpreted by Time Machine as new data to backup. Excluding the folder these backups are stored in will eliminate this effect.
    *Backups WAY Too Large*
    If an initial full backup or subsequent incremental backup is tens or hundreds of Gigs larger than expected, check to see that all unwanted external hard disks are still excluded from Time Machine backups.
    This includes the Time Machine backup drive ITSELF. Normally, Time Machine is set to exclude itself by default. But on rare occasions it can forget. When your backup begins, Time Machine mounts the backup on your desktop. (For Time Capsule users it appears as a white drive icon labeled something like “Backup of (your computer)”.) If, while it is mounted, it does not show up in the Time Machine Prefs “Do not back up” list, then Time Machine will attempt to back ITSELF up. If it is not listed while the drive is mounted, then you need to add it to the list.
    *FileVault / Boot Camp / iDisk Syncing*
    Note: Leopard has changed the way it deals with FileVault disk images, so it is not necessary to exclude your Home folder if you have FileVault activated. Additionally, Time Machine ignores Boot Camp partitions as the manner in which they are formatted is incompatible. Finally, if you have your iDisk Synced to your desktop, it is not necessary to exclude the disk image file it creates as that has been changed to a sparsebundle as well in Leopard.
    If none of the above seem to apply to your case, then you may need to attempt to compress the disk image in question. We'll consider that if the above fails to explain your circumstance.
    Cheers!

  • NVidia PNY GeForce 6600 AGP Flashing Issue (ROM says too large for EEPROM)

    Here's a puzzle for anyone willing to assist (I've heard japamac has a good history with this sort of thing so *fingers crossed*).
    So, I got a Quicksilver Power Mac G4 recently for free (gotta love the university just throwing stuff away) and it was the 800Mhz Single Core model. I've recently acquired a Sonnet 1GHz upgrade cpu nib from a thrift shop for $7 and also got my hands on a free and working PNY 6600 AGP card (256mb). I had recalled the 6600 having the ability to flash a mac rom so I thought it would be a sure thing, especially after having done similar build-up for my old Dual 500 Gigabit Ethernet machine, instead opting for an ATI 9600 and a 1.8 sonnet proc which I then sold for $180 bundled with Leopard.
    I followed this tutorial (https://discussions.apple.com/thread/2645959?start=0&tstart=0) and downloaded the latest nvflash and the rom image hosted on the site. According to windows the rom file is 32kb, and when I opened up nvflash it stated the rom already installed was around 64kb. I followed all instructions to a t and even opted to erase the eeprom as was suggested after backing up stock.rom.
    So far so good...however when I try to flash the nvmac.rom file, I keep getting some error about a PCI board id not matching (having to override w/ yes) shortly before getting an error message that states that the .rom image is too large for the eeprom. How is this possible?
    The card in question is a PNY GeForce 6600 256MB DDR DVI-VGA-TV AGP Video Card G606600ABD25T+BC4BCA
    Am I just SOL because it actually is too large, or am I missing something here? I've re-flashed the stock.rom back onto the card and all works well on the windows front, but I was really hoping to have a mac 6600 on the cheap...any suggestions?
    If you need any specific info, just ask. Will try to respond asap. Other than the rom size error message, every other step of that tutorial works just fine.

    Unless I am missing something, the 6600 ROMs on the Mac Elite site all (3) show a 128 KB size. The 6600 PNY is listed as 128, and a download and check of the file confirms it.
    If your cards ROM is 64 KB, you will need to solder a new, larger chip on the board.
    Did you download a 6200 ROM?

  • I have a 500 GB hard drive and a 1TB Time Capsule running on a MacBook Pro.  It was all working well until the MacBook went in for a repair a week or so ago.  Since then, TC will not perform a backup;  instead, it says the backup is too large for the disk

    Since having my MacBook Pro repaired (for a video problem) Time Capsule returns the following message:  "This backup is too large for the backup disk. The backup requires 428.08 GB but only 192.14 GB are available."
    I notice that there is also a new sparse bundle.
    Since TC has my ONLY backup (going back about 4 years) I am reluctant to wipe it and start over fresh as I am afraid of losing files. 
    Is there a way of dealing with this?
    I am using Snow Leopard 10.6.8

    The repair shop likely replaced a major circuit board on your MacBook Pro, so Time Machine thinks that you have a "new" computer and it wants to make a new complete backup of your Mac.
    You are going to have to make a decision to either add another new Time Capsule....or USB drive to your existing Time Capsule....and in effect start over with a new backup of your Mac and then move forward again.
    For "most" users, I think this is probably the best plan because you preserve all your old backups in case you need them at some point, and you start over again with a new Time Capsule so you have plenty of room for years of new backups.
    Or, as you have mentioned, you have the option of erasing the Time Capsule drive and starting all over again. The upside is that you start over and have plenty of room for new backups. The downside is that you lose years of backups.
    Another option....trying to manually delete old backups individually....is tricky business....and very time consuming. To get an idea of what is involved here, study this FAQ by Pondini, our resident Time Capsule and Time Machine expert on the Community Support area. In particular, study the pink box.
    http://web.me.com/pondini/Time_Machine/12.html
    Once you look through this, I think you may agree that this type of surgery is not for the faint of heart.  I would suggest that you consider this only if one of the other options just cannot work for you.

  • Mac Mini display is too large for screen on only one user account

    Okay, so I left my two year olds alone for a minute playing the "alphabet game" on my Mac Mini. They only had the keyboard, no mouse but managed to muck up my display leaving me a bit frustrated.  The screen is now too large for my Samsung display. The only way to see everything (dock, top bar, etc) is to move my mouse arrow to the end of my display and see it roll back onto the page.  I've checked the settings there and they are fine. The MacBook Pro plugs right in and is proper resolution. So I then wondered if another account on the Mac Mini would do the same thing. I logged out of my Admin account and into another and everything looks just dandy. I log back into my Admin account and it's too large and blurry again. The resolution is set correct at 1920x1080 at 60 Hz.
    What button did they push on my keyboard that would do this and how do I get it back?? Aargh! Thanks all!

    Ha, figured it out myself from another discussion forum finally. Thoght I'd share in case anyone else runs into this. They must have hit "Zoom" by htting the "Control" and scroll buttons at the same time..
    Resolution:
    You can zoom out by holding down the Option and Command buttons on the keyboard and, while you hold them down, pressing the - key. 

  • Page header plus page footer too large for the page in crystal report 2008.

    Hi,
    when we selecting pieview and print after entering paramter it's showing error: page header plus page footer too large for the page. error in File.rpt page header or page footer loanger than page. and it's not showing print layout format if i connect another printer it's showing layout designe. and some times it's showing letter formate and if i give print it's taking default lamdscape but we setup defual setup for printer 10*12 inches in particular printer.please guide me how we can solve this issues.
    regds,
    samapth

    This is a really hard post to read. See if you can take a bit of time to reword it, but one thing I do understand is that you are getting this error:
    page header plus page footer too large for the page.
    Typically, you can trust that if the error is thrown, it is true. E.g.; this is not one of those errors that says one thing, and means another. I suspect that you have some field(s) in the header(s) that grow, depending on the data. If there is too much data or the data is too long ( a text for example), the error will be thrown. To resolve this, see if placing the field(s) into a group footer / header will help.
    Ludek

  • ERROR : OpenDoc CR to PDF - File is too large for attachment.

    We are getting the following error in 3.1 using an OpenDoc call when we call a large Crystal Report to PDF format...
    Error : 52cf6f8f4bbb6d3.pdf File is too large for attachment.
    It runs OK from BOE when given parameters that returned 44 pages. (PDF = 139 KB)
    We get the error on a parameter-set that returns 174 pages when run via CR Desktop or as a SCHEDULED Instance. (PDF = 446 KB).
    Client application can't use the SDKs to SCHEDULE Instances - only configured for OpenDoc calls.....
    The BOE server is running on SOLARIS - and it's is a 2 Server CMS-Cluster.
    The problem is SPORADIC, so I am thinking the issue is related to a specific setting on one of the servers.
    Any thoughts on where to start looking...?

    Problem is _not _with the number of Rows returned - it is an issue with the size of the PDF file that it is trying to move.
    Found a possible WINDOWS solution on BOB - need to find if there is an equivalent for SOLARIS...
    Check the dsws.properties on web server D:\Program Files\Business Objects\Tomcat55\webapps\dswsbobje\WEB-INF\classes
    See if you can change any parameter to remove size limitation.
    #Security measure to limit total upload file size
    maximumUploadFileSize = 10485760

Maybe you are looking for