Also, you probably will need to set LRECL= 9999 or some large number on the filename statements to avoid truncation. Richard ... View more

One solution is to remove the first line before Proc Import.  It means that the files get read twice, which for many large files can be an issue. filename have '<existing CSV>' ; filename want '<edited CSV>' ; data _Null_ ;      infile have ;      file want ;      input ;      if _N_ = 1 then return ;      put _infile_ ; Run ; If you are using base SAS rather then EG it is possible to do a Proc Import, then press F4 to retrieve the submitted code (which is just a SAS datastep) and edit it to skip the first line.  Then use the edited datastep instead of Proc Import.  Only worth doing if all your files have the same layout and column names, and the layout/names are unlikely to change.. Richard ... View more

If you are familiar with Proc Report you could create computed columns for targets and over/under results. Alternately, is your target an overall target for the organisation?  Or do you have departmental targets?  If there are departmental targets you could create a table of targets by department and merge it back to the dataset you have.  If it is a single target you could use a macro variable : %Let AnnualTarget = 1000000 ;     /*     Insert current annual target     */ %Let Target = %Sysevalf (&AnnualTarget / 12) ;     /*     Monthly target     */ Data want ;      Set have ;      Retain target &Target ;      <other calculations, as required > Run ; Richard ... View more

To deal with numbers of the order of 1e395 as an integer without loss of precision you would need a machine representation of around 165 bytes (against SAS use of floating point 8 bytes - which does not allow even 2**64 precision).  Using scientific notation does not change this requirement.  The example using Proc Groovy demonstrates there are other tools (Java, in this instance - I showed my age in mentioning Fortran) which can accommodate very large numbers. You should use those tools.  Any attempt to carry out numerical analysis on this scale in SAS is an exercise in futility. Richard ... View more

It seems that the quantity <<root.Header>> is not character.  You may need to use the PUT( ) function to convert the value to a character for comparison in the When clause. Richard ... View more

@FriedEgg I'm very grateful to you for drawing my attention to Proc DS2, which is a very recent addition to SAS.  I looked at the definition of Float which implies Double allows precision of over 25 significant digits (though the definition is hazy on this point, and the word 'approximate'  in the definition is a bit of a worry).  So 32 digit precision might be possible within Proc DS2 and Proc FedSQL.  But Bigint is limited to 19 digit precision, so I doubt the OP could use these techniques on his data. My question still is, what is the OP doing with with such large numbers? The age of the universe is currently reckoned at 13.8 billion years or 4.36e20 seconds. The observable universe diameter is 8.948e26 meters and even converting that to Angstrom or Planck units will not require 100 significant digits. The number of atoms in the observable universe is estimated to be between 1e79 and 1e83, counting the total number of particles would only add a couple of orders of magnitude. Richard ... View more

To work with numbers with a very large number of significant digits (as in 5.039220013916026846870204011588e+395) you need to use Fortran or some other application that allows arbitrarily large numbers.  SAS, in common with most applications such as MS Excel, uses the operating system's floating point number storage mechanism which in the case of Windows and Unix allows a maximum of 8 bytes, some of which are used for the sign and the exponent.  In practice this allows for 15 digits accuracy (16 for integers provided the initial digit is not 9).  zOS allows another digit or so because it uses fewer bits for the exponent. Oracle (apparently) allows 12 bytes to floating point numbers which allows 23 digits accuracy. You can treat these numbers as character strings, compute the length to determine the exponent, substring the first n characters for the numerical result, and insert a decimal to make it look like the result you want.  But you cannot use the result in calculations in SAS.  In the format you specify you cannot even import the data in exponential format because the total width of the informat is limited to 32 characters which includes the exponent, decimal point, signs, and 'e'. In practical terms it is hard to see where a precision of even 32 digits would be required. Richard ... View more

I think the term you want is 'Slowly Changing Dimension'.  Typically this would apply where one of the addresses is regarded as current while the others are previous addresses.  Again, typically, there would be 'From' and  'To' dates associated with the records to show the history.  The latest record would have a null 'To' date, or one far in the future such as 31DEC9999.  A separate column might also be used to flag which record is the current one, to simplify queries. Richard ... View more

You can probably do this in a single datastep using multiple set statements but a 2 step process using Transpose might be easier to follow /* First get dates */ Proc Transpose data = V8                          out = pivot                          prefix = Date                          ;      By     Id ;      Var    Date ; Run ; /*     Then merge with remaining data for first row     */ data v10 ;          merge pivot (Keep = ID Date:)                     V8 (Drop = Date)                     ;      By     Id ;      If       First.ID ; Run ; [untested code - might have to fiddle with the transposed date names] Richard Message was edited by: Richard Carson ... View more

HK_EndeavourForever You say "this is a limitation in SAS I guess" but it is really a limitation in the CSV conventions - because there is no standard and thus different implementations publish and resolve embedded characters differently.  It would be quite possible, though tedious, to write SAS code to import the kind of data you have, but if you are happy to add the extra Access steps in your process that is a good enough solution (for now!). Richard ... View more