Solomon Object Model

Solomon Dynamics 6.5

I've put posts out before about this model and read through all of the 
current posts.  But, I still don't have a full idea of wether I can use the 
object model for this or not.  Please let me know if this would be a good 
time to try implementing the object model.

We are creating our own Timecard web application.  We were planning on using 
the object model at some point to make sure the data entered will be valid 
before it hits the database.  I'm not sure if we are going to use the object 
model directly everytime someone enters time, so we could have live 
up-to-date reports.  Or, if we would store the data temporarily in our own 
tables then import the data into the solomon tables.

If we were to try to use the object model to import the data directly into 
the tables everytime a user entered data would we also have to use the 
transaction import?  Or can we write our own procedures to get the data in?  
And if we allow the user to enter the data directly with the object model do 
we have to log into solomon and have it running to enter the information?  

If Solomon,(the app), has to be logged into in order to use the object model 
then I think we will have to store the information into our own tables then 
have someone do somekind of import process to get the data into the tables.

If any one has had experience with the object model and somekind of web app 
and could reply to this I would appreciate it.

I think I just don't have a full understanding of when to use and how to use 
the object model.

Thanks,

Barry,

Thanks for the insight.  I know we are planning on using the .net languages 
to implement our timecard.  I was just wondering if when the program is 
running and logged into solomon that it counts as a user?  We only bought a 
few licenses to log in so if we have too many trying to log in someone would 
be kicked out or the Object model may not be able to log in.



"Barry Flynn" wrote:

> I'll offer a couple of thoughts.
> 
> I can think of three ways of entering data into Solomon tables.
> 1. Directly populate the tables
> 2. Use Transaction Import
> 3. Use the Object Model.
> 
> ------------------
> 
> Unless you REALLY know what you are doing, I don't recommend directly 
> populating the tables.
> If you do that, you are assuming responsibility for enforcing logical 
> integrity etc.
> 
> ------------------
> 
> With both TI and the Object Model, data is "entered via the
appropriate 
> Solomon screen", so that screen enforces integrity just as it would do
so if 
> a humen was entering the same data into the same screen.
> 
> Both TI and the Object Model can have their "lottle quirks".
> And, sometimes, "major quirks" :)
> 
> ------------------
> 
> TI requires that Solomon be running.
> Effectively, you are running a Solomon input screen - except that the data

> being entered is coming from a disk file.
> 
> With TI, by one means or another, you create a data file on disk.
> You also require a TI Control File which, as a minimum, identifies the 
> fields in the data file.
> There are two flavours of control file - Simple (which I've never used) and

> Intelligent.
> In intelligent control files, you can write BSL code (sort of just like
VB3) 
> to apply some logic should that be necessary.
> 
> You then start the TI process.
> You can do so :-
> - By using Solomon's TI screen, or
> - By witing some code in a VBTools screen, or
> - by (possibly proggraatically) running it from the Command Line.
> 
> Here's a bit of Solomon's 4.5 Help on how to start it from the command line

> (4.5 is the easiest version for me to look at as I type this. I don't think

> the rules have changed.)
> 
>
--------------------------------------------------------------------------------
--------------------
> 
> Starting Transaction Import from a Command Line
> 
> To execute a Transaction Import process from the command line, use a
command 
> line similar to the following:
> 0101000.EXE [TI]TM=1 [TI]TC=ABC.CTL [TI]TD=ABC.DTA [TI]TO=ABC.OUT [TI]TL=1

> [TI]TE [TI]Minimize=Y
> [TI]TM =<#>   - Transaction Mode ( default
>        is 1 )
>      1 - Edit Only
>      2 - Combine Edit and Update
>      3 - Update after successful
>          Edit
> [TI]TD=<filename>  - Data Filename
> [TI]TC=<filename>  - Control Filename
> 
> [TI]TO=<filename>  - Output Filename
> [TI]TL=<#>   - Logging info ( default is 0 )
>      0 - Nothing
>      1 - All Data lines and
>          messages
>      2 - Just Bad Data Lines and
>          messages
> [TI]TE=<#>   - Number of errors to stop after
>      ( default is 20 )
> [TI]Minimize=<Y|N>  Y - Yes, run the app
>      minimized
>      N - No, run the app in normal
>      mode
> 
> This command line executes Journal Transactions (01.010.00) in the General

> Ledger module and does the following:
> 
> · Imports the data from the file Abc.dta.
> · Uses the control file Abc.ctl.
> · Creates the output log file Abc.out.
> · Logs all messages and data.
> · Stops after 20 errors.
> · Runs in Edit Only mode.
> · Runs minimized.
> 
> (c) 1999 Solomon Software
> 
>
-------------------------------------------------------------------------------
> 
> The big thing about TI is that you can't interact with it.
> You fire it up.
> You wait for it to finish.
> Then you (or the operator) look at the Log to try to see if it was 
> successful.
> To my knowledge, the only way to see if it was successful is to look
through 
> the Log it produces.
> 
> There's a reasonably good coverage of TI in the Solomon Help system.
> (And possibly the manuals...)
> In Help, look at :-
> System Series / System Manager / Importing Transaction Data
> Then hit "next" a lot of times :)
> 
> That's the 4.5 help system - Help may be structured a little differently in

> later versions.
> 
> 
> ------------------
> 
> The Object Model achieves a similar end, but is quite different.
> Firstly, you need to have "a program" which is going to be
running the show.
> This could be VB6, or Dot.Net code from your "other system".
> Or I believe it could possibly be VBA code inside an Excel spreadsheet.
> Etc.
> Be a little cautious though - there may be "odd quirks" with
running the 
> Solomon Object Model from some of those platforms.
> 
> I believe that you have the Object Model Developers Guide.
> You may want to look at the heading "What You Can and Can't Do with
the 
> Solomon Object Model"
> 
> Shortly after that section, the guide has a section on "Feeder
Systems", and 
> then goes on to a little section on "Object Model vs. Transaction
Import".
> 
> Like TI, the Object Model also requires that Solomon be running.
> But, unlike TI, it can start Solomon.
> This is covered in the Guide in a section headed "Logging in to a
Company".
> That section also discusses interesting situations that can occur depending

> on whether a human is already logged in to Solomon on that workstation.
> 
> Then you fire up the screen you want to automate, and, control by control,

> poke in the required data.
> You are able to intercept, and appropriately handle, any errors or messages

> that may occur.
> You tell it when to Save.
> In short, your code is running the show.
> 
> As I see it, the two big things about the Object Model are:-
> - Unlike TI, you are interacting with it all the way.
> - But, that does mean that you are writing code to do so - possibly quite a

> lot of it.
> And your code has to handle the various error conditions that might arise.
> 
> ----------------
> 
> I've run out of puff.
> I'll leave it at that - for the moment.
> I hope I haven't got too many of my facts wrong !! :)
> 
> Barry
> 
> -- 
> Barry Flynn
> Complete Solutions DG
> 
> 
> "Justin Jones" <JustinJones@discussions.microsoft.com>
wrote in message 
> news:C2EB6573-708F-41FB-985C-710F73D9D7E5@microsoft.com...
> > Solomon Dynamics 6.5
> >
> > I've put posts out before about this model and read through all of
the
> > current posts.  But, I still don't have a full idea of wether I can
use 
> > the
> > object model for this or not.  Please let me know if this would be a
good
> > time to try implementing the object model.
> >
> > We are creating our own Timecard web application.  We were planning on

> > using
> > the object model at some point to make sure the data entered will be
valid
> > before it hits the database.  I'm not sure if we are going to use the

> > object
> > model directly everytime someone enters time, so we could have live
> > up-to-date reports.  Or, if we would store the data temporarily in our
own
> > tables then import the data into the solomon tables.
> >
> > If we were to try to use the object model to import the data directly
into
> > the tables everytime a user entered data would we also have to use
the
> > transaction import?  Or can we write our own procedures to get the
data 
> > in?
> > And if we allow the user to enter the data directly with the object
model 
> > do
> > we have to log into solomon and have it running to enter the
information?
> >
> > If Solomon,(the app), has to be logged into in order to use the object

> > model
> > then I think we will have to store the information into our own tables

> > then
> > have someone do somekind of import process to get the data into the 
> > tables.
> >
> > If any one has had experience with the object model and somekind of
web 
> > app
> > and could reply to this I would appreciate it.
> >
> > I think I just don't have a full understanding of when to use and how
to 
> > use
> > the object model.
> >
> > Thanks,
> >
> > Justin Jones 
> 
> 

I was also wondering.  If we create a program that will accomplish using the 
Object Model does it need to live on the same server as the Solomon app 
parent?

"Justin Jones" wrote:

> Barry,
> 
> Thanks for the insight.  I know we are planning on using the .net languages

> to implement our timecard.  I was just wondering if when the program is 
> running and logged into solomon that it counts as a user?  We only bought a

> few licenses to log in so if we have too many trying to log in someone
would 
> be kicked out or the Object model may not be able to log in.
> 
> 
> 
> "Barry Flynn" wrote:
> 
> > I'll offer a couple of thoughts.
> > 
> > I can think of three ways of entering data into Solomon tables.
> > 1. Directly populate the tables
> > 2. Use Transaction Import
> > 3. Use the Object Model.
> > 
> > ------------------
> > 
> > Unless you REALLY know what you are doing, I don't recommend directly

> > populating the tables.
> > If you do that, you are assuming responsibility for enforcing logical

> > integrity etc.
> > 
> > ------------------
> > 
> > With both TI and the Object Model, data is "entered via the
appropriate 
> > Solomon screen", so that screen enforces integrity just as it
would do so if 
> > a humen was entering the same data into the same screen.
> > 
> > Both TI and the Object Model can have their "lottle
quirks".
> > And, sometimes, "major quirks" :)
> > 
> > ------------------
> > 
> > TI requires that Solomon be running.
> > Effectively, you are running a Solomon input screen - except that the
data 
> > being entered is coming from a disk file.
> > 
> > With TI, by one means or another, you create a data file on disk.
> > You also require a TI Control File which, as a minimum, identifies the

> > fields in the data file.
> > There are two flavours of control file - Simple (which I've never
used) and 
> > Intelligent.
> > In intelligent control files, you can write BSL code (sort of just
like VB3) 
> > to apply some logic should that be necessary.
> > 
> > You then start the TI process.
> > You can do so :-
> > - By using Solomon's TI screen, or
> > - By witing some code in a VBTools screen, or
> > - by (possibly proggraatically) running it from the Command Line.
> > 
> > Here's a bit of Solomon's 4.5 Help on how to start it from the command
line 
> > (4.5 is the easiest version for me to look at as I type this. I don't
think 
> > the rules have changed.)
> > 
> >
--------------------------------------------------------------------------------
--------------------
> > 
> > Starting Transaction Import from a Command Line
> > 
> > To execute a Transaction Import process from the command line, use a
command 
> > line similar to the following:
> > 0101000.EXE [TI]TM=1 [TI]TC=ABC.CTL [TI]TD=ABC.DTA [TI]TO=ABC.OUT
[TI]TL=1 
> > [TI]TE [TI]Minimize=Y
> > [TI]TM =<#>   - Transaction Mode ( default
> >        is 1 )
> >      1 - Edit Only
> >      2 - Combine Edit and Update
> >      3 - Update after successful
> >          Edit
> > [TI]TD=<filename>  - Data Filename
> > [TI]TC=<filename>  - Control Filename
> > 
> > [TI]TO=<filename>  - Output Filename
> > [TI]TL=<#>   - Logging info ( default is 0 )
> >      0 - Nothing
> >      1 - All Data lines and
> >          messages
> >      2 - Just Bad Data Lines and
> >          messages
> > [TI]TE=<#>   - Number of errors to stop after
> >      ( default is 20 )
> > [TI]Minimize=<Y|N>  Y - Yes, run the app
> >      minimized
> >      N - No, run the app in normal
> >      mode
> > 
> > This command line executes Journal Transactions (01.010.00) in the
General 
> > Ledger module and does the following:
> > 
> > · Imports the data from the file Abc.dta.
> > · Uses the control file Abc.ctl.
> > · Creates the output log file Abc.out.
> > · Logs all messages and data.
> > · Stops after 20 errors.
> > · Runs in Edit Only mode.
> > · Runs minimized.
> > 
> > (c) 1999 Solomon Software
> > 
> >
-------------------------------------------------------------------------------
> > 
> > The big thing about TI is that you can't interact with it.
> > You fire it up.
> > You wait for it to finish.
> > Then you (or the operator) look at the Log to try to see if it was 
> > successful.
> > To my knowledge, the only way to see if it was successful is to look
through 
> > the Log it produces.
> > 
> > There's a reasonably good coverage of TI in the Solomon Help system.
> > (And possibly the manuals...)
> > In Help, look at :-
> > System Series / System Manager / Importing Transaction Data
> > Then hit "next" a lot of times :)
> > 
> > That's the 4.5 help system - Help may be structured a little
differently in 
> > later versions.
> > 
> > 
> > ------------------
> > 
> > The Object Model achieves a similar end, but is quite different.
> > Firstly, you need to have "a program" which is going to be
running the show.
> > This could be VB6, or Dot.Net code from your "other
system".
> > Or I believe it could possibly be VBA code inside an Excel
spreadsheet.
> > Etc.
> > Be a little cautious though - there may be "odd quirks" with
running the 
> > Solomon Object Model from some of those platforms.
> > 
> > I believe that you have the Object Model Developers Guide.
> > You may want to look at the heading "What You Can and Can't Do
with the 
> > Solomon Object Model"
> > 
> > Shortly after that section, the guide has a section on "Feeder
Systems", and 
> > then goes on to a little section on "Object Model vs. Transaction
Import".
> > 
> > Like TI, the Object Model also requires that Solomon be running.
> > But, unlike TI, it can start Solomon.
> > This is covered in the Guide in a section headed "Logging in to a
Company".
> > That section also discusses interesting situations that can occur
depending 
> > on whether a human is already logged in to Solomon on that
workstation.
> > 
> > Then you fire up the screen you want to automate, and, control by
control, 
> > poke in the required data.
> > You are able to intercept, and appropriately handle, any errors or
messages 
> > that may occur.
> > You tell it when to Save.
> > In short, your code is running the show.
> > 
> > As I see it, the two big things about the Object Model are:-
> > - Unlike TI, you are interacting with it all the way.
> > - But, that does mean that you are writing code to do so - possibly
quite a 
> > lot of it.
> > And your code has to handle the various error conditions that might
arise.
> > 
> > ----------------
> > 
> > I've run out of puff.
> > I'll leave it at that - for the moment.
> > I hope I haven't got too many of my facts wrong !! :)
> > 
> > Barry
> > 
> > -- 
> > Barry Flynn
> > Complete Solutions DG
> > 
> > 
> > "Justin Jones" <JustinJones@discussions.microsoft.com>
wrote in message 
> > news:C2EB6573-708F-41FB-985C-710F73D9D7E5@microsoft.com...
> > > Solomon Dynamics 6.5
> > >
> > > I've put posts out before about this model and read through all
of the
> > > current posts.  But, I still don't have a full idea of wether I
can use 
> > > the
> > > object model for this or not.  Please let me know if this would
be a good
> > > time to try implementing the object model.
> > >
> > > We are creating our own Timecard web application.  We were
planning on 
> > > using
> > > the object model at some point to make sure the data entered will
be valid
> > > before it hits the database.  I'm not sure if we are going to use
the 
> > > object
> > > model directly everytime someone enters time, so we could have
live
> > > up-to-date reports.  Or, if we would store the data temporarily
in our own
> > > tables then import the data into the solomon tables.
> > >
> > > If we were to try to use the object model to import the data
directly into
> > > the tables everytime a user entered data would we also have to
use the
> > > transaction import?  Or can we write our own procedures to get
the data 
> > > in?
> > > And if we allow the user to enter the data directly with the
object model 
> > > do
> > > we have to log into solomon and have it running to enter the
information?
> > >
> > > If Solomon,(the app), has to be logged into in order to use the
object 
> > > model
> > > then I think we will have to store the information into our own
tables 
> > > then
> > > have someone do somekind of import process to get the data into
the 
> > > tables.
> > >
> > > If any one has had experience with the object model and somekind
of web 
> > > app
> > > and could reply to this I would appreciate it.
> > >
> > > I think I just don't have a full understanding of when to use and
how to 
> > > use
> > > the object model.
> > >
> > > Thanks,
> > >
> > > Justin Jones 
> > 
> > 

I'll offer a couple of thoughts.

I can think of three ways of entering data into Solomon tables.
1. Directly populate the tables
2. Use Transaction Import
3. Use the Object Model.

------------------

Unless you REALLY know what you are doing, I don't recommend directly 
populating the tables.
If you do that, you are assuming responsibility for enforcing logical 
integrity etc.

------------------

With both TI and the Object Model, data is "entered via the appropriate 
Solomon screen", so that screen enforces integrity just as it would do so
if 
a humen was entering the same data into the same screen.

Both TI and the Object Model can have their "lottle quirks".
And, sometimes, "major quirks" :)

------------------

TI requires that Solomon be running.
Effectively, you are running a Solomon input screen - except that the data 
being entered is coming from a disk file.

With TI, by one means or another, you create a data file on disk.
You also require a TI Control File which, as a minimum, identifies the 
fields in the data file.
There are two flavours of control file - Simple (which I've never used) and 
Intelligent.
In intelligent control files, you can write BSL code (sort of just like VB3) 
to apply some logic should that be necessary.

You then start the TI process.
You can do so :-
- By using Solomon's TI screen, or
- By witing some code in a VBTools screen, or
- by (possibly proggraatically) running it from the Command Line.

Here's a bit of Solomon's 4.5 Help on how to start it from the command line 
(4.5 is the easiest version for me to look at as I type this. I don't think 
the rules have changed.)

--------------------------------------------------------------------------------
--------------------

Starting Transaction Import from a Command Line

To execute a Transaction Import process from the command line, use a command 
line similar to the following:
0101000.EXE [TI]TM=1 [TI]TC=ABC.CTL [TI]TD=ABC.DTA [TI]TO=ABC.OUT [TI]TL=1 
[TI]TE [TI]Minimize=Y
[TI]TM =<#>   - Transaction Mode ( default
       is 1 )
     1 - Edit Only
     2 - Combine Edit and Update
     3 - Update after successful
         Edit
[TI]TD=<filename>  - Data Filename
[TI]TC=<filename>  - Control Filename

[TI]TO=<filename>  - Output Filename
[TI]TL=<#>   - Logging info ( default is 0 )
     0 - Nothing
     1 - All Data lines and
         messages
     2 - Just Bad Data Lines and
         messages
[TI]TE=<#>   - Number of errors to stop after
     ( default is 20 )
[TI]Minimize=<Y|N>  Y - Yes, run the app
     minimized
     N - No, run the app in normal
     mode

This command line executes Journal Transactions (01.010.00) in the General 
Ledger module and does the following:

· Imports the data from the file Abc.dta.
· Uses the control file Abc.ctl.
· Creates the output log file Abc.out.
· Logs all messages and data.
· Stops after 20 errors.
· Runs in Edit Only mode.
· Runs minimized.

(c) 1999 Solomon Software

-------------------------------------------------------------------------------

The big thing about TI is that you can't interact with it.
You fire it up.
You wait for it to finish.
Then you (or the operator) look at the Log to try to see if it was 
successful.
To my knowledge, the only way to see if it was successful is to look through 
the Log it produces.

There's a reasonably good coverage of TI in the Solomon Help system.
(And possibly the manuals...)
In Help, look at :-
System Series / System Manager / Importing Transaction Data
Then hit "next" a lot of times :)

That's the 4.5 help system - Help may be structured a little differently in 
later versions.


------------------

The Object Model achieves a similar end, but is quite different.
Firstly, you need to have "a program" which is going to be running the
show.
This could be VB6, or Dot.Net code from your "other system".
Or I believe it could possibly be VBA code inside an Excel spreadsheet.
Etc.
Be a little cautious though - there may be "odd quirks" with running
the 
Solomon Object Model from some of those platforms.

I believe that you have the Object Model Developers Guide.
You may want to look at the heading "What You Can and Can't Do with the 
Solomon Object Model"

Shortly after that section, the guide has a section on "Feeder
Systems", and 
then goes on to a little section on "Object Model vs. Transaction
Import".

Like TI, the Object Model also requires that Solomon be running.
But, unlike TI, it can start Solomon.
This is covered in the Guide in a section headed "Logging in to a
Company".
That section also discusses interesting situations that can occur depending 
on whether a human is already logged in to Solomon on that workstation.

Then you fire up the screen you want to automate, and, control by control, 
poke in the required data.
You are able to intercept, and appropriately handle, any errors or messages 
that may occur.
You tell it when to Save.
In short, your code is running the show.

As I see it, the two big things about the Object Model are:-
- Unlike TI, you are interacting with it all the way.
- But, that does mean that you are writing code to do so - possibly quite a 
lot of it.
And your code has to handle the various error conditions that might arise.

----------------

I've run out of puff.
I'll leave it at that - for the moment.
I hope I haven't got too many of my facts wrong !! :)

Barry

-- 
Barry Flynn
Complete Solutions DG


"Justin Jones" <JustinJones@discussions.microsoft.com> wrote in
message 
news:C2EB6573-708F-41FB-985C-710F73D9D7E5@microsoft.com...
> Solomon Dynamics 6.5
>
> I've put posts out before about this model and read through all of the
> current posts.  But, I still don't have a full idea of wether I can use 
> the
> object model for this or not.  Please let me know if this would be a good
> time to try implementing the object model.
>
> We are creating our own Timecard web application.  We were planning on 
> using
> the object model at some point to make sure the data entered will be valid
> before it hits the database.  I'm not sure if we are going to use the 
> object
> model directly everytime someone enters time, so we could have live
> up-to-date reports.  Or, if we would store the data temporarily in our own
> tables then import the data into the solomon tables.
>
> If we were to try to use the object model to import the data directly into
> the tables everytime a user entered data would we also have to use the
> transaction import?  Or can we write our own procedures to get the data 
> in?
> And if we allow the user to enter the data directly with the object model 
> do
> we have to log into solomon and have it running to enter the information?
>
> If Solomon,(the app), has to be logged into in order to use the object 
> model
> then I think we will have to store the information into our own tables 
> then
> have someone do somekind of import process to get the data into the 
> tables.
>
> If any one has had experience with the object model and somekind of web 
> app
> and could reply to this I would appreciate it.
>
> I think I just don't have a full understanding of when to use and how to 
> use
> the object model.
>
> Thanks,
>
> Justin Jones 

Barry,  

Thanks for all of your replies.  I found out from the technical white papers 
on the object model that when you use it you are using one of your seats.  
For example our company owns 3 seats for Solomon, 3 users can be logged in at 
the same time.  If we were to use the object model then we would have to make 
sure that when we were running the program for it that we had a seat open.  
If not I'm sure we would run into some kind of exception.  So, we are 
re-thinking using the object model b/c we want our databases to be as real 
time as possible.  to use the object model we would have to use somekind of 
batch at night to run it so we would alway be a little behind.  

Thanks,

Justin Jones

"Barry Flynn" wrote:

> Justin
> 
> << I was just wondering if when the program is
> >> running and logged into solomon that it counts as a user?
> 
> Not a strong point of mine, but I don't think a license is used until your

> object model code fires up an app.
> I have vague memories of a problem in this area a while ago, where the 
> license was not released when the App was closed.
> Not sure about that though...
> 
> << I know we are planning on using the .net languages
> >> to implement our timecard.
> 
> There have been some comments about odd problems in Closing & Logging
Out 
> (etc.) when Dot Net code is running Solomon via the object model.
> But I think it might vary for different Solomon versions.
> 
> The only object model code I have written is from VB6 programs, so I
haven't 
> had that problem.
> 
> I think you might want to consider writing a very skeletal program which 
> "just" logs in, fires up the App you want to "talk to",
pokes some 
> hard-coded data into that screen, then Saves & Closes.
> See what issues you run into.
> See if you have license problems.
> 
> << If we create a program that will accomplish using the
> > Object Model does it need to live on the same server as the Solomon
app
> > parent?
> 
> I'm not aware of any requirements in that regard.
> Apart from the ever-present issue of Dot Net Trust, I don't think it
matters 
> where you program lives.
> The requirement is that it runs on a machine which is able to run Solomon 
> (ie a human user is able to fire up Solomon on that machine.)
> 
> Hope that helps...
> 
> Barry
> 
> -- 
> Barry Flynn
> Complete Solutions DG
> 
> 
> "Justin Jones" <JustinJones@discussions.microsoft.com>
wrote in message 
> news:DBE5581E-DF8A-4053-9EA7-9FFDCB07A501@microsoft.com...
> >I was also wondering.  If we create a program that will accomplish
using 
> >the
> > Object Model does it need to live on the same server as the Solomon
app
> > parent?
> >
> > "Justin Jones" wrote:
> >
> >> Barry,
> >>
> >> Thanks for the insight.  I know we are planning on using the .net

> >> languages
> >> to implement our timecard.  I was just wondering if when the
program is
> >> running and logged into solomon that it counts as a user?  We only
bought 
> >> a
> >> few licenses to log in so if we have too many trying to log in
someone 
> >> would
> >> be kicked out or the Object model may not be able to log in.
> >>
> >>
> >>
> >> "Barry Flynn" wrote:
> >>
> >> > I'll offer a couple of thoughts.
> >> >
> >> > I can think of three ways of entering data into Solomon
tables.
> >> > 1. Directly populate the tables
> >> > 2. Use Transaction Import
> >> > 3. Use the Object Model.
> >> >
> >> > ------------------
> >> >
> >> > Unless you REALLY know what you are doing, I don't recommend
directly
> >> > populating the tables.
> >> > If you do that, you are assuming responsibility for enforcing
logical
> >> > integrity etc.
> >> >
> >> > ------------------
> >> >
> >> > With both TI and the Object Model, data is "entered via
the appropriate
> >> > Solomon screen", so that screen enforces integrity just
as it would do 
> >> > so if
> >> > a humen was entering the same data into the same screen.
> >> >
> >> > Both TI and the Object Model can have their "lottle
quirks".
> >> > And, sometimes, "major quirks" :)
> >> >
> >> > ------------------
> >> >
> >> > TI requires that Solomon be running.
> >> > Effectively, you are running a Solomon input screen - except
that the 
> >> > data
> >> > being entered is coming from a disk file.
> >> >
> >> > With TI, by one means or another, you create a data file on
disk.
> >> > You also require a TI Control File which, as a minimum,
identifies the
> >> > fields in the data file.
> >> > There are two flavours of control file - Simple (which I've
never used) 
> >> > and
> >> > Intelligent.
> >> > In intelligent control files, you can write BSL code (sort of
just like 
> >> > VB3)
> >> > to apply some logic should that be necessary.
> >> >
> >> > You then start the TI process.
> >> > You can do so :-
> >> > - By using Solomon's TI screen, or
> >> > - By witing some code in a VBTools screen, or
> >> > - by (possibly proggraatically) running it from the Command
Line.
> >> >
> >> > Here's a bit of Solomon's 4.5 Help on how to start it from
the command 
> >> > line
> >> > (4.5 is the easiest version for me to look at as I type this.
I don't 
> >> > think
> >> > the rules have changed.)
> >> >
> >> >
--------------------------------------------------------------------------------
--------------------
> >> >
> >> > Starting Transaction Import from a Command Line
> >> >
> >> > To execute a Transaction Import process from the command
line, use a 
> >> > command
> >> > line similar to the following:
> >> > 0101000.EXE [TI]TM=1 [TI]TC=ABC.CTL [TI]TD=ABC.DTA
[TI]TO=ABC.OUT 
> >> > [TI]TL=1
> >> > [TI]TE [TI]Minimize=Y
> >> > [TI]TM =<#>   - Transaction Mode ( default
> >> >        is 1 )
> >> >      1 - Edit Only
> >> >      2 - Combine Edit and Update
> >> >      3 - Update after successful
> >> >          Edit
> >> > [TI]TD=<filename>  - Data Filename
> >> > [TI]TC=<filename>  - Control Filename
> >> >
> >> > [TI]TO=<filename>  - Output Filename
> >> > [TI]TL=<#>   - Logging info ( default is 0 )
> >> >      0 - Nothing
> >> >      1 - All Data lines and
> >> >          messages
> >> >      2 - Just Bad Data Lines and
> >> >          messages
> >> > [TI]TE=<#>   - Number of errors to stop after
> >> >      ( default is 20 )
> >> > [TI]Minimize=<Y|N>  Y - Yes, run the app
> >> >      minimized
> >> >      N - No, run the app in normal
> >> >      mode
> >> >
> >> > This command line executes Journal Transactions (01.010.00)
in the 
> >> > General
> >> > Ledger module and does the following:
> >> >
> >> > · Imports the data from the file Abc.dta.
> >> > · Uses the control file Abc.ctl.
> >> > · Creates the output log file Abc.out.
> >> > · Logs all messages and data.
> >> > · Stops after 20 errors.
> >> > · Runs in Edit Only mode.
> >> > · Runs minimized.
> >> >
> >> > (c) 1999 Solomon Software
> >> >
> >> >
-------------------------------------------------------------------------------
> >> >
> >> > The big thing about TI is that you can't interact with it.
> >> > You fire it up.
> >> > You wait for it to finish.
> >> > Then you (or the operator) look at the Log to try to see if
it was
> >> > successful.
> >> > To my knowledge, the only way to see if it was successful is
to look 
> >> > through
> >> > the Log it produces.
> >> >
> >> > There's a reasonably good coverage of TI in the Solomon Help
system.
> >> > (And possibly the manuals...)
> >> > In Help, look at :-
> >> > System Series / System Manager / Importing Transaction Data
> >> > Then hit "next" a lot of times :)
> >> >
> >> > That's the 4.5 help system - Help may be structured a little

> >> > differently in
> >> > later versions.
> >> >
> >> >
> >> > ------------------
> >> >
> >> > The Object Model achieves a similar end, but is quite
different.
> >> > Firstly, you need to have "a program" which is
going to be running the 
> >> > show.
> >> > This could be VB6, or Dot.Net code from your "other
system".
> >> > Or I believe it could possibly be VBA code inside an Excel
spreadsheet.
> >> > Etc.
> >> > Be a little cautious though - there may be "odd
quirks" with running 
> >> > the
> >> > Solomon Object Model from some of those platforms.
> >> >
> >> > I believe that you have the Object Model Developers Guide.
> >> > You may want to look at the heading "What You Can and
Can't Do with the
> >> > Solomon Object Model"
> >> >
> >> > Shortly after that section, the guide has a section on
"Feeder 
> >> > Systems", and
> >> > then goes on to a little section on "Object Model vs.
Transaction 
> >> > Import".
> >> >
> >> > Like TI, the Object Model also requires that Solomon be
running.
> >> > But, unlike TI, it can start Solomon.
> >> > This is covered in the Guide in a section headed
"Logging in to a 
> >> > Company".
> >> > That section also discusses interesting situations that can
occur 
> >> > depending
> >> > on whether a human is already logged in to Solomon on that
workstation.
> >> >
> >> > Then you fire up the screen you want to automate, and,
control by 
> >> > control,
> >> > poke in the required data.
> >> > You are able to intercept, and appropriately handle, any
errors or 
> >> > messages
> >> > that may occur.
> >> > You tell it when to Save.
> >> > In short, your code is running the show.
> >> >
> >> > As I see it, the two big things about the Object Model are:-
> >> > - Unlike TI, you are interacting with it all the way.
> >> > - But, that does mean that you are writing code to do so -
possibly 
> >> > quite a
> >> > lot of it.
> >> > And your code has to handle the various error conditions that
might 
> >> > arise.
> >> >
> >> > ----------------
> >> >
> >> > I've run out of puff.
> >> > I'll leave it at that - for the moment.
> >> > I hope I haven't got too many of my facts wrong !! :)
> >> >
> >> > Barry
> >> >
> >> > -- 
> >> > Barry Flynn
> >> > Complete Solutions DG
> >> >
> >> >
> >> > "Justin Jones"
<JustinJones@discussions.microsoft.com> wrote in message
> >> > news:C2EB6573-708F-41FB-985C-710F73D9D7E5@microsoft.com...
> >> > > Solomon Dynamics 6.5
> >> > >
> >> > > I've put posts out before about this model and read
through all of 
> >> > > the
> >> > > current posts.  But, I still don't have a full idea of
wether I can 
> >> > > use
> >> > > the
> >> > > object model for this or not.  Please let me know if
this would be a 
> >> > > good
> >> > > time to try implementing the object model.
> >> > >
> >> > > We are creating our own Timecard web application.  We
were planning 
> >> > > on
> >> > > using
> >> > > the object model at some point to make sure the data
entered will be 
> >> > > valid
> >> > > before it hits the database.  I'm not sure if we are
going to use the
> >> > > object
> >> > > model directly everytime someone enters time, so we
could have live
> >> > > up-to-date reports.  Or, if we would store the data
temporarily in 
> >> > > our own
> >> > > tables then import the data into the solomon tables.
> >> > >
> >> > > If we were to try to use the object model to import the
data directly 
> >> > > into
> >> > > the tables everytime a user entered data would we also
have to use 
> >> > > the
> >> > > transaction import?  Or can we write our own procedures
to get the 
> >> > > data
> >> > > in?
> >> > > And if we allow the user to enter the data directly with
the object 
> >> > > model
> >> > > do
> >> > > we have to log into solomon and have it running to enter
the 
> >> > > information?
> >> > >
> >> > > If Solomon,(the app), has to be logged into in order to
use the 
> >> > > object
> >> > > model
> >> > > then I think we will have to store the information into
our own 
> >> > > tables
> >> > > then
> >> > > have someone do somekind of import process to get the
data into the
> >> > > tables.
> >> > >
> >> > > If any one has had experience with the object model and
somekind of