Loading ...
Sorry, an error occurred while loading the content.

Re: Duplicate index on Link Query (From Deferred to Physical)

Expand Messages
  • Omar Lamin
    Hi, me again. Just to add that it can go as far as possibly adding a [Magic Special] setting in the Magic.INI so that it will make the default be Physical
    Message 1 of 23 , Nov 1, 2008
    • 0 Attachment
      Hi, me again.

      Just to add that it can go as far as possibly adding a [Magic
      Special] setting in the Magic.INI so that it will make the default be
      Physical rather than Deferred.

      http://tech.groups.yahoo.com/group/magicu-l/message/132706

      The title on this thread (which I did not produce), does make me
      smile.

      I don't think we use this settings where I work, because it is anyway
      deeply coded in our genetic code not to leave things to Deferred
      unless advised otherwise. You should see the torturing techniques we
      have elaborated to apply to those who fail to comply :-).

      Omar,
      --- In magicu-l@yahoogroups.com, "Omar Lamin" <omar.lamin@...> wrote:
      >
      > Hi,
      >
      > Covering the details of what Physical and Deferred transactions
      imply
      > is beyond what can be done through posting on this group. Our
      > migration V8 to V9 class, devotes almost two hours on the subject of
      > transaction processing and the introduction of Deferred.
      >
      > The subject was also addressed in bits and pieces through several
      > threads on this group. Below is an example of a post where I share
      the
      > essence of what I do not like about deferred:
      >
      > http://tech.groups.yahoo.com/group/magicu-l/message/126436
      >
      > What is expressed in the above post brings me to stick to Physical
      > which has been the rock solid working default for Magic until
      Version 9.
      >
      > You could also search the archive on the search argument 'Deferred'
      > and you will get a lot of discussions that took place about it. It
      is
      > a recurring subject here because it is the default proposed and one
      > needs to be told or find by himself (which takes much longer) that
      in
      > a desktop context, Joker is the name, Poker is the game and Physical
      > is the 90%+ right default Transaction Processing strategy :-)
      >
      > You also do not see too many people here on this group stating:
      > "I strongly disagree with Omar, I use Deferred for desktop
      everywhere
      > and don't see any problem with it..."
      >
      > My guess for that is not that people are shy to contradict here, but
      > rather that most (if not close to all) simply use Physical by
      default.
      > Please note that I am talking about default, not that Deferred
      should
      > never ever be used. I do use it some times.
      >
      > You want to proceed in a manner to prove us all to be wrong. Go
      ahead,
      > be my guess. I will welcome any confirmation that it is so if it is
      at
      > the end.
      >
      > Good luck,
      > Omar
      > "Amazing what one default setting can be the cause of..."
      >
      > "A butterfly wings flap in a par of the world can be at the base of
      > the cause for a major storm taking place in another part of the
      world
      > at some later time."
      >
      > --- In magicu-l@yahoogroups.com, "magi_kero" <magi_kero@> wrote:
      > >
      > > Hi Omar, I have around 50 Master/Detail Online tasks using
      Deferred
      > > transactions, excluding Masterfile forms and Process controls
      > > interfaces. Programs that allows updates are already set with
      Locking
      > > Strategy = 'On Modify' and Access mode (Ctrl+D) = Write/Write..
      while
      > > programs for record viewing purposes (Select programs, View
      Account
      > > Ledger, reports, etc) are set with Locking Strategy = 'No Lock'
      and
      > > Access mode = Read/Write.
      > >
      > > May i know why would it be advisable to use Physical but
      Transaction
      > > begin should be set to 'On record lock'?
      > >
      > > Way back before, i first encountered disadvantages with Deferred
      when
      > > I tried to apply Steve's demo program about record-locking (that
      > > program which could identify who's locking the record, record is
      > > being updated, etc..). That should have put me to consider
      shifting
      > > to Physical but I was so impressed then with Deferred's ability
      to
      > > cancel/undo changes by just pressing F2, and above all, not
      allowing
      > > partial updates to records when errors are encountered. These
      were
      > > all achieve without extra programming effort.
      > >
      > > With Physical, how do you achieve those available features under
      > > Deferred? And in general, preserving data integrity (specially in
      > > Master/Detail tasks)?
      > >
      > >
      > > --- In magicu-l@yahoogroups.com, "Omar Lamin" <omar.lamin@> wrote:
      > > >
      > > > Hi,
      > > >
      > > > I for sure agree with what Keith proposed.
      > > >
      > > > My guess is that you most likely have merit for coming up with
      what
      > > > ever you came up with on this first iteration. However,
      starting on
      > > > solid ground (some sort of formal training) is a key in getting
      up
      > > to
      > > > speed efficiently even more so with Magic.
      > > >
      > > > BTW, there are over the web training sessions from time to
      time. Not
      > > > expensive and you do get an expert to yack about the basic and
      > > > important things for hours with demos and Powerpoints...
      > > >
      > > > This being said,
      > > > How many Online tasks is your application made of currently?
      > > > How long would it take you to just go through and change all the
      > > > 'Deferred' to 'Physical'?
      > > > Also:
      > > > - Transaction start should be: 'On Record Lock'
      > > > - Locking should be 'On modify'
      > > > The access property of any table you plan to read only and not
      write
      > > > to should be set to: Access = Read, Share = Write
      > > >
      > > > Unless you would plan to switch (convert) your application
      to 'Rich
      > > > Client' in a real future, It is my strong guess that no matter
      what
      > > > happens from the above, it will be less problems and much easier
      > > > problems to understand and fix if you do the above as if you
      leave
      > > > things to 'Deferred' and cross your fingers on it.
      > > >
      > > > Omar,
      > > > "There is never enough time to do things right. However, there
      is
      > > > always forever to deal with the consequences for something not
      to be
      > > > right from the start."
      > > > --- In magicu-l@yahoogroups.com, "magi_kero" <magi_kero@> wrote:
      > > > >
      > > > > We'll I should thank you for the constructive critic. I am
      only a
      > > > > beginner of Magic, and this is my first ever project. And I
      > > should
      > > > > consider the points you have raised, considering your solid
      > > > > experiences with Magic.
      > > > >
      > > > > If only there is that someone in my country, seasoned and
      > > experienced
      > > > > with Magic and can provide solid training, I may have not
      fall
      > > into
      > > > > developing application using Deferred Transaction. The lone
      > > supplier
      > > > > could not even deliver the Intermediate Training Course,
      lacking
      > > > > their skills.
      > > > >
      > > > > But through this experience uncovers the programming issues
      which
      > > > > will become the guide for projects to come in the future.
      > > > >
      > > > > --- In magicu-l@yahoogroups.com, "Keith Canniff" <kcanniff@>
      > > wrote:
      > > > > >
      > > > > > Well if you have a time constraint, I guess you have to do
      > > what's
      > > > > necessary
      > > > > > to make your deadline.
      > > > > >
      > > > > > However, history dictates that when you want to go back and
      > > clean
      > > > > up things
      > > > > > after you've gotten something into production RARELY
      HAPPENS.
      > > > > >
      > > > > > The reason is that there's always new features people want,
      > > bugs to
      > > > > fix, and
      > > > > > deadlines to meet.
      > > > > >
      > > > > >
      > > > > >
      > > > > > It seems to me that you've built your application around
      some
      > > > > possibly
      > > > > > incorrect premises.
      > > > > >
      > > > > >
      > > > > >
      > > > > > First, few people (even those that have been around
      > > > > Magic/eDeveloper/UniPaaS
      > > > > > for years) understand deferred transactions properly.
      > > Therefore
      > > > > building an
      > > > > > entire application around this as I'm guessing one of your
      > > first
      > > > > projects is
      > > > > > problematic at best.
      > > > > >
      > > > > >
      > > > > >
      > > > > > Second, a basic concept of using the same key both
      ascending
      > > (main
      > > > > table)
      > > > > > and descending (linked table to get the last line# used)
      was
      > > > > something you
      > > > > > weren't taught. This again raises concerns that the
      > > application
      > > > > may be
      > > > > > built on shaky principals.
      > > > > >
      > > > > >
      > > > > >
      > > > > > Understand, this is not a criticism of you. I've taught
      Magic
      > > > > classes since
      > > > > > 1988 and have had many students that were seasoned veterans
      of
      > > > > programming
      > > > > > and even Magic that simply did not know how this language
      > > worked and
      > > > > > probably put 2-3 times more effort into them than was
      needed to
      > > > > simply get a
      > > > > > solution for their client and/or employer.
      > > > > >
      > > > > >
      > > > > >
      > > > > > My STRONG suggestion would be to get someone to look over
      your
      > > > > application
      > > > > > and give you an assessment of how solid it is. This will
      give
      > > you a
      > > > > far
      > > > > > better answer than someone just throwing out suggestions
      based
      > > on
      > > > > this
      > > > > > thread in the user group.
      > > > > >
      > > > > >
      > > > > >
      > > > > > I'm sure you want to build the best product for your
      company
      > > that
      > > > > performs
      > > > > > efficiently and is easy to understand and maintain. An
      > > assessment
      > > > > will help
      > > > > > you to understand just how close you are to obtaining the
      above
      > > > > goals and
      > > > > > how "at risk" your company may be in deploying the current
      > > > > application.
      > > > > >
      > > > > >
      > > > > >
      > > > > > Ultimately it will be your decision. I just think based on
      this
      > > > > thread that
      > > > > > another set of eyes might come in handy, and there are many
      > > > > qualified people
      > > > > > in this group that could help.
      > > > > >
      > > > > >
      > > > > >
      > > > > > Keith
      > > > > >
      > > > > >
      > > > > >
      > > > > > From: magicu-l@yahoogroups.com [mailto:magicu-
      > > l@yahoogroups.com] On
      > > > > Behalf
      > > > > > Of magi_kero
      > > > > > Sent: Wednesday, October 29, 2008 9:34 PM
      > > > > > To: magicu-l@yahoogroups.com
      > > > > > Subject: [magicu-l] Re: Duplicate index on Link Query
      > > > > >
      > > > > >
      > > > > >
      > > > > > I am thinking of setting the Locking Strategy = No Lock for
      all
      > > my
      > > > > > Online Tasks with Deferred/Within Deferred transactions and
      a
      > > > > > combination probably of Isolation Levels as a temporary
      remedy.
      > > And
      > > > > I
      > > > > > may have to allow "Lost Update" in this situation... UNLESS
      > > > > convinced
      > > > > > that these strategies will not really work. OR, does no one
      has
      > > > > ever
      > > > > > used Deferred Transactions for Online Tasks?
      > > > > >
      > > > > > In our setup, where branches only have 1 or 2 application
      users
      > > > > > (Sales and Inventory publish over Citrix), and with
      table/file
      > > > > > separated by Branch Code in the file path/name (application
      > > uses
      > > > > > btrieve gateway), I'm thinking that record locking problems
      may
      > > > > occur
      > > > > > at a very minimal instances.
      > > > > >
      > > > > > With the time constraints, I cannot just imagine re-
      creating
      > > all
      > > > > the
      > > > > > programs to Physical, and with all the batch tasks to be
      added
      > > to
      > > > > > clean up dirty data and preserve integrity. And probably
      > > > > implementing
      > > > > > memory tables to be used for online tasks/user interface.
      > > > > >
      > > > > > But your opinions on this matter will be greatly considered.
      > > > > >
      > > > > > --- In magicu-l@yahoogroups.com <mailto:magicu-l%
      > > > > 40yahoogroups.com> , "Omar
      > > > > > Lamin" <omar.lamin@> wrote:
      > > > > > >
      > > > > > > "But to change the programs to Physical is not an option
      > > > > > > for me at this time. Deployment is scheduled in 3 weeks
      time,
      > > so i
      > > > > > > will have to find workarounds instead, and maybe create
      > > another
      > > > > > > version (implementing Physical transaction) after
      deployment."
      > > > > > >
      > > > > > > I would just go ahead and change to 'Physical'. Things
      are
      > > not
      > > > > going
      > > > > > > to collapse on you. Maybe (not certain) a bit of extra
      > > contention
      > > > > > > ("Waiting for Lock " in a Multi-user environment) to deal
      > > with and
      > > > > > > refine at the beginning. However, my guess is that you
      will
      > > have
      > > > > > less
      > > > > > > and easier to trace problems when deploying Physical as
      you
      > > will
      > > > > > have
      > > > > > > leaving it blindly and fingers crossed to deferred.
      > > > > > >
      > > > > > > Omar,
      > > > > > > --- In magicu-l@yahoogroups.com <mailto:magicu-l%
      > > > > 40yahoogroups.com> ,
      > > > > > "magi_kero" <magi_kero@> wrote:
      > > > > > > >
      > > > > > > > I agree, creating another index for this purpose is
      > > > > > unnecessary... I
      > > > > > > > have removed the 2nd index and used your suggestion.
      > > However, I
      > > > > > may
      > > > > > > > have to totally disregard the Link/Query (Index DSC)
      method
      > > > > when
      > > > > > in
      > > > > > > > Deferred Transaction (Online Task) due to critical
      errors I
      > > > > have
      > > > > > > > encountered, as follows:
      > > > > > > >
      > > > > > > > 1. When I tried to delete a record and enter a new
      record,
      > > on
      > > > > > Exit,
      > > > > > > > the task will somewhat become not responsive (hanged).
      > > Trying
      > > > > > Ctrl+G
      > > > > > > > in the table also does not work (hanged). - I think the
      > > table
      > > > > is
      > > > > > > > being locked, but no message.
      > > > > > > >
      > > > > > > > 2. When I tried to delete a record and enter a new
      record,
      > > on
      > > > > > Quit,
      > > > > > > > the task will close but when I tried to view again that
      > > same
      > > > > > range of
      > > > > > > > records, the program becomes unresponsive. - I believe
      > > reason
      > > > > is
      > > > > > same
      > > > > > > > with item#1.
      > > > > > > >
      > > > > > > > I have tried the following solutions and both solves
      the
      > > hang
      > > > > > problem:
      > > > > > > > 1. Changed the Locking Strategy to No Lock
      > > > > > > > 2. Removed the Link/Query on table same with the Main
      table.
      > > > > > > >
      > > > > > > > I'm beginning to realize now the disadvantages with
      using
      > > > > > Deferred
      > > > > > > > Transactions. But to change the programs to Physical is
      not
      > > an
      > > > > > option
      > > > > > > > for me at this time. Deployment is scheduled in 3 weeks
      > > time,
      > > > > so
      > > > > > i
      > > > > > > > will have to find workarounds instead, and maybe create
      > > another
      > > > > > > > version (implementing Physical transaction) after
      > > deployment.
      > > > > > > >
      > > > > > > >
      > > > > > > > --- In magicu-l@yahoogroups.com <mailto:magicu-l%
      > > > > 40yahoogroups.com> ,
      > > > > > "Steven G. Blank" <sgblank@>
      > > > > > > > wrote:
      > > > > > > > >
      > > > > > > > > I've successfully used your technique with one
      possibly-
      > > > > > significant
      > > > > > > > > difference: instead of creating a separate descending
      > > index,
      > > > > I
      > > > > > use
      > > > > > > > > the same index in the link operation and just change
      > > > > > > > it's "Direction"
      > > > > > > > > property to Descending/Reversed.
      > > > > > > > >
      > > > > > > > > I suspect your problem is caused by something else,
      such
      > > as
      > > > > > (for
      > > > > > > > > example) invoking a Deferred transaction or a
      Physical
      > > > > > transaction
      > > > > > > > > with a scope that encompasses multiple records.
      > > > > > > > >
      > > > > > > > > Steve Blank
      > > > > > > > >
      > > > > > > > >
      > > > > > > > > At 11:15 PM 10/27/2008, you wrote:
      > > > > > > > > >I have a table (OR_dtl) with indeces:
      > > > > > > > > > 1. ORtype+ORnumber+Line#(Asc) >> Unique (Line# is
      > > > > > Ascending)
      > > > > > > > > > 2. ORtype+ORnumber+Line#(Dsc) >> Unique (Line# is
      > > > > > Descending)
      > > > > > > > > >
      > > > > > > > > >In the program, I use Task property / Index=1 but
      > > include a
      > > > > > > > Link/Query
      > > > > > > > > >to same table using Index=2. The purpose of this is
      to
      > > > > > increment
      > > > > > > > the
      > > > > > > > > >Line with the last Line# output from the Link/Query
      > > Index=2.
      > > > > > This
      > > > > > > > works
      > > > > > > > > >fine except that trying to delete a record will fail
      and
      > > > > > returns
      > > > > > > > error
      > > > > > > > > >message citing Duplicate Index in OR_dtl.dat file.
      > > > > > > > > >
      > > > > > > > > >Is using this method of incrementing Line#
      advisable? OR
      > > > > > should I
      > > > > > > > use a
      > > > > > > > > >Real field in the header file to contain the last
      Line#
      > > in
      > > > > dtl
      > > > > > > > table.
      > > > > > > > >
      > > > > > > >
      > > > > > >
      > > > > >
      > > > > >
      > > > > >
      > > > > >
      > > > > >
      > > > > > [Non-text portions of this message have been removed]
      > > > > >
      > > > >
      > > >
      > >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.