>>I have an application to build that will accept records comming from the serial port and write them back to MS SQL Server 6.5
>>
>>
>>My biggest fear is that the application won't have time to treat a record before a new one show up in the serial port.
>>
>>Now, for my questions:
>>- Is my fear justified?
>
> I haven't tried processing 3 requests per second, but I can't imagine it should be a problem. I've been playing around with something that does something similar, and the approach I've taken (which you mentioned) is to have two different applications. The first application creates a timer object that fires every (x) ms and checks for data in the MSComm control. If it finds something, it inserts it into a table. That's about all it does.
>
> The second program handles the processing and communicating with the backend. It also creates a timer object that fires at some period. When it does, I shut off the timer, grab all the new entries, flag them as being "in use" and attempt to send them to the backend. If it works, I change the "in use" flag to "sent". If it doesn't, I reset the flag. Then I turn the timer back on. Actually, I'm using a logical field along with a DateTime() stamp, but the idea is the same.
>
>>- Wich development tool is better for this job: VB or VFP?
>
> I debated this also. VB has a smaller memory footprint, but I ended up using VFP since it was easier/faster for me to use. I didn't have to worry about ODBC or anything. And I know more about VFP than VB. But I'm sure VB would have worked just fine.
>
>>- Should I use the standard MSComm or is there a better ActiveX available?
>
> MSComm seemed OK for me.
>
>>- Should I try to write the record directly to the SQL Server or should I write it to a temporary file/table (low overhead) and treat that file/table in batch at night?
>>
> I like the two program approach better, because if something takes longer than I expected, I have less of a chance of losing things.
>
>Good luck.
>
>-Paul

I'm using similar strategy here for IPX messages firing across 100 PCs. One timer collates the messages to a form array, another timer processes the array. Works as well as can be expected with IPX (loses messages - different issue).