Which SAS tool works the best for user manual data entry?

[Chi_spc]

Hi All,

I am totally new to SAS software. We are a manufacturing company and are now implementing SAS Analytics package for data mining, process improvements, etc.

What I am responsible for is to bring in Statistical Process Control (SPC) for our production process for real-time data monitoring. One of our requirements is for the shop floor operator to perform manual data entry to SAS and data should be updated right away on the Shewhart charts.

Is SAS Web Reporting Studio the right tool for us to build, configure and use the UI for user manual data entry?  Or any other SAS tool will be the best fit?

I have heard from some other companies that they develop C#, .NET, Java, JavaScript, etc. for frontend data entry. Our company's ultimate goal is that our manufacturing engineers will be able to develop, modify and maintain the frontend user-interface (UI) so that they do not need to rely on our MIS developers to do so. Our engineers are familiar with JMP script so we are trying to stick with SAS programming.

Hope anyone would provide recommendations. Thanks.

Jeff

[Reeza]

There's SAS/AF but that's very old school.

Generally, I don't consider SAS to be a data entry tool, more of an analytical tool. Depending on how big you expect your data to get you probably do want to have some different options. I'm not familiar with JMP so I can't say if that's an option or not.

Another option is Access DB...again old school but works well for data entry.

[twocanbazza]

I think you can upload data from the Excel via AMO - you could do something with that but I do agree with Reeza I wouldn't consider SAS as data entry tool.

Barry

[ccaulkins9]

as long as you have Microsoft add-ins installed?

[SASKiwi]

I would say a lot depends on your data entry requirements. How much data is involved? Do you require simultaneous updating from multiple users? Does this data need to be linked to data from other sources?  Do you need roll-back and recovery if a particular transaction fails?

If you want robust, simultaneous multi-user data entry then I would recommend a transactional database such as Oracle, SQL Server etc. There are a multitude of data-entry front-ends to these databases.

Then SAS can be used to read the transactional database on a near real-time basis to satisfy your reporting requirements.

[Chi_spc]

Thanks for all your replies!

I would say we need to do manual data entry pretty heavily. We have about 400 test parameters, 30 production lines, manual data entry every 15 minutes for each line, by different operators. So for every hour we have 400 * 30 * 15 * 4 = 720k data transactions.

Actually we are using a 3rd party SPC software now and it supports frontend manual data entry functionality and is pretty easy to be setup and configured. However it does have many other limitations and lack of scalability. That is why we are looking into SAS. So my point is, we are hoping SAS will be easier, more user-friendly and more robust than our current one. But if SAS' frontend data entry is not that good, it will be a big hit of its evaluation scores.

By the way, I have heard of using the SAS Web Reporting Studio plus the Stored Processes are doable for manual data entry. I will try to dig in it and hope for more luck

[Quentin]

I agree with SASKiwi.

I would use a transactional database to store your data.  And choose whatever front end you want to enter data into it.

Then you can have SAS pull data from the database and make the control charts.  You could set up some web forms in Web Report Studio or Stored Process Web App so that engineers could go to a web page, pass a few parameters, and generate charts on demand. Once you have the data, it's basically a single call to PROC SHEWART to make a chart.  You could have a scheduled job that looks for alert conditions and emails warnings, etc.

I love SAS.  But if your argument is "we should by SAS so that we can make control charts", I wouldn't be surprised if some of the dedicated SPC software options are cheaper.   If they know JMP already, that might be an option.  Of course, if you get some of your engineers excited about playing with their data, SAS will let them do much more than just SPC....

[Reeza]

SAS is an analytical product, great for analyzing data, but there really isn't very much for data entry developed plain and simple.

If you're looking for a good tool from front to end, you generally have to compromise somewhere and data entry is one of them.

You can always talk to a SAS sales person though, they can help analyze your specific situation and provide workarounds and how difficult they might be.

[art297]

@Chi-spc: Jeff,

A couple of months ago I did a contract for a company that could well have been the company you work for.  I can't talk about specifics as I had to sign an NDA, but I can talk about the general SAS related issues.

When you mention data entry, data entry is a broad term.  In the manufacturing project I worked on, the bulk of the data were measurements that were being generated by another system.  The only manual data entry tasks were simple tables that the engineers could enter as a simple data step in SAS.

If your data entry needs are similar, than SAS might be all you need.  The question I think you need to address is how complex of a data entry process you feel you need.  Do the entries need to be verified using a double entry process?  Do the entries need to be validated using one or more sets of rules?  Do the tables need to be saved according to a particular file naming structure?

Art

[Chi_spc]

Could someone give me comments on the downsides of using SAS as the frontend UI for manual data entry?

Thanks.

[Quentin]

Hi Again,

I would suggest you head to lexjansen.com, which is a site that indexes SAS user group papers.  And search there for "data entry".  A quick glance didn't result in much that looked appealing to me.  Note that many of the papers that are returned are about old technologies (SAS/AF, SAS/FSP) which I think were mostly designed for single user interfaces running on a local PC.   And if you're going to do entry on one PC, might as well just use MS Access or similar.

I did notice this paper, on using SAS/IntRnet to create web forms.   You could do similar using today.  But still doesn't look that appealing to me.:

http://analytics.ncsu.edu/sesug/1999/092.pdf

This a more recent paper, describes a solution to web data entry using open source tools which SAS is happy to talk to on the back end, and also discusses some of the limitations of SAS/AF and SAS/FSP which led them to develop their solution.

http://www.wuss.org/proceedings10/Applications/2946_9_APP-Penix.pdf

HTH,

--Q.

[SASKiwi]

Your data entry requirements sound quite heavy. One of the key difficulties with SAS is dealing with simultaneous multi-user updates. Base SAS simply cannot handle simultaneous updating of SAS datasets by different users and you end up with file-locking errors (a search through these forums using the key words FILE and LOCK could be enlightening).

SAS/SHARE is an extra SAS product that can handle this but in my experience is not widely used by SAS customers. You could try batch updating, say each user entering data into their own SAS dataset and then combining these with your own file-locking logic into a combined dataset. But to be honest it’s still a kludge and potentially unreliable.

If you want an industrial-strength, multi-user data-entry solution I suggest you consider a transaction database (Oracle, Sybase, SQL Server, MySQL etc.) linked to a user interface of your choice. 

[DannyDizzy]

Hi,

we use as you suggested stored processes with prompts (to limit the user input varaity) with drop down lists opened in WRS. Works fine for us but I dont know the input-limits for this.
BR

Daniel

[AllanBowe]

Bit late to the party but we built a tool that covers this exact use case. It works on Base SAS, SAS 9 EBI, and Viya 3.5 / Viya 4.

It's a web application that allows controlled updates to particular tables, or even particular rows within a table, according to configuration.

It's zero code - data is validated according to the metadata (lengths / types etc) as well as any additional validations that you set up.

It's free for 5 users and there are a bunch of videos here:  https://docs.datacontroller.io/videos/