Design advice required...

Hi

I've been using VBA for a few years, but only recently (within the past couple of weeks) stated using VB.net.

I've been given the job designing a small app to sit on a Win CE barcode scanner, save scanned barcodes & user entered data. Nothing too complex* and I'm looking for more advice on design rather than implementation (right now anyway...)

1. The scanned data needs to be held somewhere; a Dataset seems overkill for this task, so I was looking at using either a DataTable, or an array. Any suggestions about which is a better option? (or if there's a something else I've missed)

2. Once all the scans have been collected, they need to be saved to a file, which will be read elsewhere. I was considering using xml for the file, but as it's got to be readable by VBA, I'd started to reconsider using a csv. Does this seem like a good solution, and is there an easy way of producing csv/xml files from a datatable/array?

3. Has anyone here used the Symbol API for Motorola/Symbol barcode readers? It's confusing, the documentation is minimal, and I'm having problems doing even the simplest of things. I know it's a fairly niche concern but thought I'd try my luck.


Any suggestions gratefully received

Kev



*mostly, anyway. See 3 for where the misery is kicking in...

As far as storing the data, I would go with a DataBase. There is a SQL Server CE version that you could use that has a small footprint. You could use ADO in VBA to access the data.

While the database idea is logical and reasonable, it's been vetoed by the IT dept, possibly because they don't like the idea of one of the great unwashed getting their hands on something fit-for-purpose. I had to fight bloody hard to simply get VB...

My idea, which I should have stated more explicitly, was to

1. collect data in array or other storage (while scanner in use)
2. write data to file (probably CSV)
3. file is synched to host PC when docked
4. VBA/ADO read from file on host, to store of data

I really wanted to know if there were easy shortcuts to achieving 1 & 2...

Thanks for the fast reply, tho.

1. Write each scanned item to CSV (if that is your preference), no need for an Array/storage. Just write the data out each and every time, File.IO is quite quick. However, that said, how is the scan conducted? - manually, with a hand saner?

I think some of the questions in this thread would be best asked in the Mobile Development Forum.

Gary

Thread moved to 'Mobile Development' forum

(thanks for letting us know Gary :thumb: )

I agree that ideally SQLCE would be your best option, but if not, CSV should be fine, and get the results to the server using HTTP or FTP.

There are examples in the symbol SDK which should get you up and running

In a way it's too bad this forum is stuck in the .Net section of the site. There are many alternatives for CE/WM development, many well supported and some cheaper and even easier to use for somebody with a VBA background than VB.Net or C#.


I'm not a fan of SQL Server Compact Edition, but it is an embedded database much like Jet ("Access") on the desktop. You don't have the issues your IT folks might be worrying about with full blown SQL Server, even Express Edition.

Some of the alternatives to .Net such as PocketBuilder or NS Basic/CE provide alternatives such as Sybase or SQLite. However there is nothing wrong with a text file for something like this ayway.


Assuming the device's CE-build contains MSMQ, that might be the more obvious solution here. Even if not in ROM I believe MSMQ can be installed as part of an application. Since this sort of device probably doesn't need to allow the operator to review and edit "items" once committed, a queue makes a lot of sense. On docking the data would simply flow to the server the queue is targeted to, and there MSMQ Triggers can be used to have the "server side" application fired off to process the data.

Admittedly MSMQ is something that shade-tree coders seem to have little experience with. But as an old (2001) article says:

Quote:

---

... the picture of MSMQ for Windows CE is exactly what you would expect for use on an often mobile, sometimes disconnected device: a space-and-resource-optimized implementation of a store-and-forward mechanism designed to support the sending and receiving of messages in an often isolated environment.

---

Pocket PC: MSMQ for Windows CE Brings Advanced Windows Messaging to Embedded Devices

.Net wraps this in the usual Framework mummy bandages, but CF should support it with no problem.

Quote:

---

Originally Posted by dilettante

I'm not a fan of SQL Server Compact Edition, but it is an embedded database much like Jet ("Access") on the desktop. You don't have the issues your IT folks might be worrying about with full blown SQL Server, even Express Edition.

---

Out of interest, what have you got against SQL Server CE?

Gary

Nothing at all, the only advantages I see in it is the ability to sync with other SQL Server Editions and its SQL & T-SQL syntax being highly compatible with its big brothers. Well that and in some devices you'll find it in ROM too.

If your shop uses something like Oracle or Sybase the advantage shrinks.

However my point was that those "IT folks" who didn't want the OP using it are probably confusing it with its bigger brothers. I was trying to suggest their concerns might be misplaced. I just wouldn't push hard in favor of using it myself, I'm pretty neutral on the subject.

Thanks for the contributions, and thanks for moving this to the Mobile Dev forum; my responses are below...

I'm now going with SQL server CE; as the user will need to review and edit the list of scanned items, the message queue is ruled out (plus I know more about SQL than MSMQ). It won't appear outside the device, so IT won't know/care.

"There are examples in the symbol SDK which should get you up and running".
I know, and I've been using them, but rather than picking an existing program to bits I'd prefer to get a language reference and learn by writing increasingly useful programs. I've had better results learning like that in the past. Unfortunately the Symbol SDK seems to be fairly niche...

"However my point was that those "IT folks" who didn't want the OP using it are probably confusing it with its bigger brothers"
Given they've barred Access & anything better, I think they're just being awkward for the hell of it. They're the main reason I've got good at using Jet/ADO with SQL in Excel; there is nothing else available.