May 23, 2014 at 4:23 am
As an accidental DBA who is really an accountant I could do with some advice. So today I was driving in the car and I was thinking about how to set up automatic stock control with RFID devices.
I kind of realised that automatic input devices are actually no different from what are normally called manual input devices ie keyboards and mice. Especially keyboards and mice with regard to enterprise applications.
Keyboards and mice are so integrated into the system many of us (or the users at least not so much people here) have long since stopped considering how they work. They are integrated into the lower parts of the operating system and are constantly listening for events. When an event happens a very specific series of procedures are triggered. Lots of different things can happen when an event happens but because there are standards in place all the receiving programs know what those events are going to be and are specifically programmed to react in certain ways..
So this led me to consider how to get information into a database from a so called "automatic" device.
A so called manual input of information into a database apart from not actually being manual in any way has the following key aspects.
The keyboard and mouse are constantly listening.
The user hits the keyboard at which point a message is sent to the computer
In the case of enterprise application that is usually
Open database (assuming its not open already)
Open Table
Go to field (the user selects the field by tabbing or clicking within it using the keyboard and mouse controls)
Input information
Rinse and repeat
So for an automatic device you need to have virtually the same thing going on.
The computer needs to be constantly listening for a message from the device
The device is triggered and sends the information to the computer
The information not being standardised needs to be interpreted
ie split / parsed etc
The database its going to need to be identified and opened
The table its going to needs to be identified and opened
And for each packet of parsed information the field that it needs to go into needs to be identified
Input can then occur.
Late as I am to the party I recognise that this has largely all been sorted out before and what is a revelation to me in a car going to work was very probably a revelation to someone brighter than myself decades ago and in fact a short net search on port listener gives me some indication that yes others have already figured out how to do this.
My question is this.
I am wanting to run a constant RFID reader that will on trigger input a PKID and a timestamp direct to a SQL Server 08R2 express backend datbase and table. Is this something that 08R2 Express can be configured to do within the product or do I need a separate program in the system tray listening to the port and then firing information to the server? I did some background reading and it is clearly possible but I could do with some specific direction as to a path which I should follow. Something like - Yes it can all be handled by 08R2 Express completely with no reference to outside program or no you will need to have a translation program in addition to 08R2 Express.
Any guidance or links to prevent me going down side allies would be very much appreciated.
cloudydatablog.net
May 23, 2014 at 4:54 am
Apologies I maybe should have posted this in the Newbie forum hadn't realised this.
cloudydatablog.net
May 23, 2014 at 5:53 am
If it were me, I would create an application that's constantly listening to receive requests. It could be an executable with an icon in the system tray, it could be a web service. Whatever it is, that would accept and validate the incoming data, then fire commands against the database. There are probably several ways to accomplish this task, but this is the way I would go with.
May 23, 2014 at 6:30 am
SQL Express is feature-lite, so I would hazard a guess that you couldn't do it directly.
I was mooching about over some StreamInsight stuff the other day. Have you had a look at that ? Would take some coding, as is not exactly 'native' to SQL.
[font="Courier New"]sqlmunkee[/font]
[font="Courier New"]Bringing joy and happiness via SQL Server since 1998[/font]
May 23, 2014 at 6:34 am
DOH! I completely missed the "express" in the OP; thanks for catching it. I agree that you don't really want to run the data to SQL Express. While it's good for development, I wouldn't use it for a production system. Personally, I don't even have it installed. I'd rather develop and test against a test environment that mimics production.
May 23, 2014 at 7:23 am
Brilliant guys and thanks for the suggestion of Streaminsight.
This has told me one I'm generally going along the right lines and express is not the thing to do it in.
Brilliant onto the next stage
cloudydatablog.net
May 23, 2014 at 7:47 am
Dalkeith (5/23/2014)
Brilliant guys and thanks for the suggestion of Streaminsight.This has told me one I'm generally going along the right lines and express is not the thing to do it in.
Brilliant onto the next stage
No problem at all. Always glad to help.
May 23, 2014 at 7:52 am
Dalkeith (5/23/2014)
Brilliant guys and thanks for the suggestion of Streaminsight.This has told me one I'm generally going along the right lines and express is not the thing to do it in.
Brilliant onto the next stage
No worries, happy to help 🙂
[font="Courier New"]sqlmunkee[/font]
[font="Courier New"]Bringing joy and happiness via SQL Server since 1998[/font]
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply