Printable View
I've got a VB6 Windows app that we want to allow a user to "push" basically a grid of data to the PPC so that they can go fill in the data in the field and then when they return to their desk sync that data back into the grid in the VB6 app.
What methods can be used to accomplish this??
Ok - doesn't anyone do stuff like this??
Should the VB6 app write a text or XML file to the PPC? How would you all handshake this type of interaction???
Hi,
I would probably use RAPI (OpenNetCF have a desktop library) - presumably you have the VB source to change?
Does the VB6 app use SqlServer - you could use replication in that case.
RAPI would let you copy a file to your PPC. You could do the collection on the PPC, and then cradle it, and kick off a transfer from the VB6 app
Pete
Looks like RAPI is for a .Net app - the workstation app is VB6.
The VB6 app is my code - so I can modify it as needed. It can "output" a file - I'm just curious what's a good technique to get that file to the PPC where it can be manipulated and then later passed back to the workstation and "imported" by that same VB6 app.
Hi,
RAPI can be used from VB6 without a problem, and looks ideal for the job you need.
http://www.unsupportedsoftware.com/p...dev/vbrapi.htm should do just what you need
Pete
After further thinking on this - the PPC will have to sync up a SQLCE db to the teachers "student" data anyway.
I guess I was thinking two steps because we have only done read-only PPC app's and if the user messes up the pw 3 times the db deletes.
But with the teacher pumping real data into the PPC this data cannot be deleted.
So I've got these dualing issues - the db with student data needs heavy protection and this 3-fail delete rule.
But the data entered by the teacher needs to be sustained somewhere.
Maybe I need to db's - one that's sync'd from the network and one for storing user data. That user data DB only need pri-key relationships to the read-only SQL CE db...
Or I can store the entered data in an XML file on the PPC so it's human readable in the event of loss of the main SQL CE db and the potential of "relationship" issues being lost being these two....
Just thinking out loud ;)
Hi,
what about replication - would that not solve your problems?
Replication to PPC rocks :)
Pete
We've got the sync'ing of the PPC SQL CE to the network DB working fine - wrote our own routine to do it since it's just a small amount of columns from very few tables in a large enterprise SQL app.
And we've got this concept in place that if they fail the pw 3 times when running the PPC app it deletes the PPC's SQL CE DB. Kind of like the admin person loses the PPC and a student finds it we don't want them getting into student data.
This has all been read only up till now - but we are going to have the gym teachers take them out in the field and record info on students.
So...that's where I'm at and started thinking about where to store the "entered on the PPC data" if the SQL CE DB on the PPC can be deleted if the user messes up the pw...
If you can't do replication, I would be considering pushing XML across a TCP connection. I did this to push tables up to a PPC (both running .NET, but neither XML nor TCP is unique to .NET), and to push tables back down.
Oh yeah, and do you really want to delete the whole DB? Creating one on the fly isn't all that much trouble, and it would be somewhat simpler to push tables either way if the DB existed, so instead of deleting the DB, why not re-create it as an empty DB?
Could you give me any code snippets on TCP connections - how you actually accomplished this?Quote:
Originally Posted by Shaggy Hiker
Our PPC DB creation is done in an interesting way. First we read a config table on the network SQL DB that tells us the names of the VIEW's that feed the PPC DB. Then we SELECT * from each of these views (on the PPC) and make tables in the PPC DB with column names and datatypes that match the VIEW's and then pump the rows into the PPC DB. Plus - as an added security benefit - the WINDOWS PW that they enter on the PPC to open the connection to the NETWORK DB is used as the encryption pw for the SQL CE DB on the PPC.Quote:
Originally Posted by Shaggy Hiker
The reason we delete the PPC DB on 3-failed attempts is so that if the PPC gets lost and found by some student they cannot review data on other students.
We can add fields to the VIEWS on the network side and they appear on the PPC without any changes to the PPC app. We even store the SELECT statements that the PPC app uses for display on the network side - so that we can modify them and add new functionality without changing the PPC app.
It's pretty quick and simple to re-sync using the method I described.
And as I said - this is where my problem comes up - we were read-only on the PPC up to now - so deleting the DB was no big deal. But now that we will be writing data and saving it on the PPC I've got to protect that entry so the user doesn't experience a loss of data.
Basically I've got gym teachers that have a network app that they can run to load "stats" on phy fitness tests. That's been in place for a year now. They want to basically leave the desk with the PPC and mark those stats on the PPC (in the field) - come back to the desk - get into the network app and "suck" the info back from the PPC - populating the grid on the network app automatically - be happy that all kids data came over - no new kids in the class - stuff like that. Hit SAVE and the network app basically writes the data it sucked from the PPC back to the network database.
So the PPC DB is really just used to allow the PPC APP to show grids of students. The data they mark on the PPC needs to be saved outside the PPC DB - as you said, maybe XML file.
Here's a link to a thread where I posted two links which show the class I had for moving data via a TCP connection that ran on a second thread. Of course, threads don't work so well in VB6, and I have no suggestion for that, but I think TCP under VB6 was actually somewhat easier.
http://www.vbforums.com/showthread.p...&highlight=TCP
Does that help? This may be the desktop version. I could post the PDA version, but it is pretty close already.
I'm just getting back into this - very, very busy few weeks here...
I'm curious - can a VB6 app on a workstation open a folder on a docked PC? what would the path be?
Or, on the other hand - can the .Net app on the PPC open a folder on the workstation it's docked to?
Are there standards for this - typical drive paths/folder names that are guaranteed to exist?
Recently I discovered that the SD chip comes in as SD CARD folder - that was not what I expected it to be...
It sure seems like there are at least a few standard folders in any of the Win mobile flavors, but I don't know if this is true for all cases or just the ones I have seen.
I don't know the answers to any of your questions, but I'll be watching this thread with some interest to see what shows up, as it may prove useful at some point.
Hi,
with RAPI, a VB6 app can certainly open a folder on the PPC, and it can search for folders and files using CeFindFirstFile and CeFindNextFile.
As far as I am aware, unless you do something with an Activesync provider, you can't go the opposite way.
As for standard names, nothing is guaranteed, especially if you are writing applications that may be deployed on a device with a foreign language rom, where 'Program Files' is no longer 'Program Files'. There are ways of dealing with this though.
As far as storage cards are concerned, again, the name varies. On the various devices around my desk it is called.
Storage Card (appears to be most popular)
SD Card
CF Card (On an Dell with 2 card slots)
To enumerat the storage cards you can
HTHCode:For Each directory As String In System.IO.Directory.GetDirectories("\") ' Enumerating all subfolders in a root folder...
If ((New System.IO.DirectoryInfo(directory)).Attributes And IO.FileAttributes.Temporary) <> 0 Then ' Picking folders with Temporary attribute set...
Console.WriteLine("Found storage card: {0}", directory)
End If
Next
Pete
@pete - thank you very much for that loop and check for storage card logic - very much appreciated!