|
Hello all,
I been working with MI since v3, and stopped
upgrades at v4.5 for our 911 system.
This has always been the *migraine* of the day, but
this system [work around] went into place over a year ago and works
perfect.
By running integration [MB included], only the
functionality that the user needs is included, thus having a lower *training
curve* with near 100% data integrity. Plenty of Dropdowns/Check
boxes/radios minimize user boo-boos, along with full validation before posting
the data. Over performance is increases by working the data in DBF format
and using native code tools to perform validation and changes that do not
disrupt the linking of the data to the graphical objects.
Anyone wishing to contact me on setting this up,
altering my application, via Delphi Integration [no installation, single
exe] or just as a consultant to your project, let me know.
Here's some of the scope and core, a little *techy*
but that's what work arounds are about.
MI DOES NOT SUPPORT *TRUE* NETWORKED FUNCTIONALLITY
! !
EACH USER RUNS A *Local* COPY OF *The
Map(s)*
You MUST be familiar [proficient] with
MapBasic or an Integrated Language, preferrable DELPHI, but c++, vb, etc will
do.
1) The local application will run a 1 minute timer
[typical max for languages 60,000 milliseconds]
Could be less
depending on PC, complexity of update [large region with lots of data], and
records in file.
2) Upon timer expiration, application will
check a folder for any existing files [updates] to process
File names are not relevant,
just the existance of the file and the system can open it [file writes
completed]
May be local or on a fileserver
with a folder for each user -- something like mailboxes for email
systems
3) Updates from the *update folder* will
be processed on a local copy of map, then the file is removed from the
folder by move [to an archieve folder] or deletion [destructive--no history]
4) Changes made by the user to the local copy will
be placed in a file according to item #2
The file name could be simply
*update* but in an archieving system this causes problems.
Suggest using a *long file
name* based on GUID which maintains a history of changes.
5) Each record MUST contain a *Globally Unique
IDentifier* [GUID] to avoid duplicate entries at ALL times
6) GUID is based on the format
uuuuu.ddddd.tttttttttttt where u=user id, d=day number since 1/1/1900, t=time
expressed as decimal of 24 hours [0.25=6am 0.5=noon 0.75=6pm]. Row numbers
are not acceptable as the number of rows in the table can become less, after
packing, which then duplicates the id's [row number] by the amount of deleted
records.
7) Update file is text based in the following
format
Status GUID
TABLE
DATA
Terminator
Status is ADD, CHANGE,
DELETE
GUID is from Item
#6
TABLE is the table name [or
alias name] -- no path or extension
DATA is the full *mapbasic
command* to perform the update, on per line
including
graphic [lines, points, etc] and data
Terminator is a unique line to
indicate the end of the processing for that record, must not be in data
section
8) Integrety Checking
Retrieve GUID
and table, then process SQL [select from table where
GUID=guid]
test returned
table record count, should be 0 or 1, if >1 then show error and
abort
For DELETE the record(s) deleted
For CHANGE if count=0 then ADD is applied otherwise the new
data is applied [update]
For ADD, if no records found then insert data,
otherwise process CHANGE
9) Creation of update files can either be upon
completion of user input or as a batch which can be integrated with the timer
function, by user activation, or by application termination but must not be
duplicated by any of the these processes
KNOWN ISSUES
It is still possible to have *cyclic exchanges*
whereby 2 users change the same record, before appling the other's chagnes, of
which each will pass to the other their changes and therefore a full record
update is not performed. The occurance of this is extremely low, but none
the less still exists. By having good policy and procedures
concerning what data being updated by each user this should not
happen.
Hope this
helps..........................
SEND RESPONSES TO: [footer is official office
use]
Trey Pattillo
==========================================================
Trey Pattillo Operations & GIS Coastal Bend 911 Network 2910 Leopard St Corpus Christi, TX 78408 ph: 1.361.881.9911 pg: 1.361.270.3908 [enter ph#] fx: 1.361.883.5749 em: [EMAIL PROTECTED] |
