PROC IMPORT encounters problem when contains a "

[Kurt_Bremser]

---

@caibird wrote:

So I need proc import.

---

No, you don't.

proc import is a helper for a quick first shot, but not meant to be used in a production environment, as it will mask changes in input data that will bite you in the behind later on. It also has to make guesses, and these may fail (as you just experience).

Computers are dumb, and if you let them make your work for you, you must be prepared to live with the consequences.

For importing data into SAS, rely on clearly defined structures and put those into data steps that do what you want, not what the computer thinks you want.

I repeat: computers are dumb.

That's why we get paid the big bucks to make them do things that make sense 😉

[caibird]

I don't need the high road statement at the moment, I need the problem solved. Besides I don't agree with you, see below:

I totally understand program is not as flexible as human brain, that's why I explicitly told it the DLM=','.

I told the PROC IMPORT all the elements needed to separate words, but it still failed, obvious it is human brain problem, either I use it wrong/missing syntax, or the PROC IMPORT has bug.

[Kurt_Bremser]

I'm with you that proc import behaves wrongly because the delimiter=','; statement should make it recognize that there are more columns than only one present. Raise an issue with SAS TS about that.

The fact that this bug is already present in my rather old 9.2 shows that it was obviously not caught by anybody for a long time, which illustrates our well-meant advice to NOT rely on proc import for heavy-duty work. Because none of the heavy SAS users use it, or they would have stumbled across this.

In the meantime, follow the advice given and write a working data step for cases where you find those quotes. data step logic is a part of SAS from the very beginning, you won't find many pieces of software that have been so rigorously tested by endusers and therefore are literally bug-free.

[Reeza]

I respectfully disagree that proc import has a bug. 

It's a guessing proc and typically the DSD option would be correct. 

It would be nice to have the option to suppress that however. 

[Kurt_Bremser]

---

@Reeza wrote:

I respectfully disagree that proc import has a bug. 

It's a guessing proc and typically the DSD option would be correct. 

It would be nice to have the option to suppress that however. 

---

Seeing it that way, you're probably right.

If the OP posts an idea for ballotting, I think I might support it, although I never use proc import.

For good reason.

[caibird]

I tend to say it is a bug rather than lack of options, for ALL information(DLM, GUESSINGROWS,etc.) provided. What's the good reason for the procedure to guess wrong? It is 100% sure. If, say, I specify guessing rows=10, and 11th or later rows went wrong, I can understand. (Or I provide ambiguous DLM and so on) If SAS documents declared the PROC IMPORT used DSD options by default and cannot be turn off, then I can also understand it is just lack of options. If it is an incorrect result out of expectation, then it is a bug.

[Reeza]

As is, I don't think what you want is possible with proc import, since the DSD option appears by default. This would be correct in 99% of cases. You can contact tech support to verify this. 

There are probably ways to automate the generation of the data step code to deal with varying number of variables depending on your rules. But since you need a proc import that won't meet your requirement.

Good Luck. 

[caibird]

Guys, thanks a lot for the help. Previous I thought it is just I am not skilled enough, something wrong in my code. Now I will look for other solution.