Thanks Brian for your answer
regards
Juan Antonio Salhus

--- El lun, 22/9/08, Brian Hancock <[EMAIL PROTECTED]> escribió:

> De: Brian Hancock <[EMAIL PROTECTED]>
> Asunto: RE: [Dataperf] Limiting number of DP users
> Para: "'Dataperfect Users Discussion Group'" <[email protected]>
> Fecha: lunes, 22 septiembre, 2008 8:05
> Hi Juan,
> 
> I cannot think of any way from within DP...  But because
> the .STR file is
> kept open by each user, depending on the network operating
> system there
> might be a way. I used to have a utility for Novell Netware
> which could keep
> track of which users had the database ( ie .STR file) open
> and it could also
> limit the number of people that could open that file
> (although I never used
> it for that) but its intention is to limit the number of
> users able to
> access a file.
> 
> The major thing I used the utility for was that you could
> "send" a popup
> message to users who had the file open, especially for the
> occasions when I
> wanted to do some maintenance.
> 
> Regards
> Brian
>   
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Juan
> A. Salhus R.
> Sent: Tuesday, 23 September 2008 8:47 AM
> To: Dataperfect Users Discussion Group
> Subject: Re: [Dataperf] Text Field in Reports annoyance...
> 
> Hi, there some option to control the qty of user using the
> same data base in
> a network?
> thanks
> Juan Antonio Salhus
> Chile 
> 
> --- El sáb, 13/9/08, Tim Rude <[EMAIL PROTECTED]>
> escribió:
> 
> > De: Tim Rude <[EMAIL PROTECTED]>
> > Asunto: Re: [Dataperf] Text Field in Reports
> annoyance...
> > Para: "Dataperfect Users Discussion Group"
> <[email protected]>
> > Fecha: sábado, 13 septiembre, 2008 4:06
> > Brian,
> > 
> > I believe it will but I've never put it to the
> full
> > test with that much text. Sounds like a good
> experiment for
> > you. :-)
> > 
> > Tim Rude
> >   ----- Original Message ----- 
> >   From: Brian Hancock 
> >   To: 'Dataperfect Users Discussion Group' 
> >   Sent: Saturday, September 13, 2008 10:29 AM
> >   Subject: RE: [Dataperf] Text Field in Reports
> > annoyance...
> > 
> > 
> >   Thanks Tim,
> > 
> >    
> > 
> >   Just the solution I needed.  I haven't ever
> bothered
> > using cat.c on long text fields as I thought it also
> might
> > have a smaller character limit, will it handle up to
> the 64k
> > allowable in a Text field?
> > 
> >    
> > 
> >    
> > 
> >   Regards
> > 
> >   Brian
> > 
> >    
> > 
> >    
> > 
> > 
> >
> ----------------------------------------------------------------------------
> --
> > 
> >   From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of
> Tim
> > Rude
> >   Sent: Saturday, 13 September 2008 11:35 PM
> >   To: Dataperfect Users Discussion Group
> >   Subject: Re: [Dataperf] Text Field in Reports
> > annoyance...
> > 
> >    
> > 
> >   Brian,
> > 
> >    
> > 
> >   Since you cannot successfully concatenate your data
> and
> > codes while outputting it, you need to concatenate it
> > *before* you output it. Create a report variable that
> > appends your starting and ending tags to the contents
> of
> > your AxAy field before outputting it all as one chunk.
> > Fortunately the cat.c function isn't limited to 78
> chars
> > as so many of the other text handling functions are.
> > 
> >    
> > 
> >   Assign RV1:
> >
> cat.c["<myhtml><!CDATA[";P1F1;"]]>"]
> > 
> >    
> > 
> >   Then in the report, output it as:
> > 
> >    
> > 
> >   #
> > 
> >   </myhtml>
> > 
> >    
> > 
> >   (where # represents RV1 formatted as A0A0)
> > 
> >    
> > 
> >   Assuming P1F1 contained your sample text, the output
> is:
> > 
> >    
> > 
> >   <myhtml><![CDATA[<br> This is some
> data
> > inside a CDATA section.
> > 
> >   The <u>Quick</u> Brown fox jumps over
> the
> > lazy dog]]>
> > 
> >   </myhtml>
> > 
> >    
> > 
> >   Tim Rude
> > 
> >     ----- Original Message ----- 
> > 
> >     From: Brian Hancck 
> > 
> >     To: 'Dataperfect Users Discussion Group' 
> > 
> >     Sent: Saturday, September 13, 2008 7:40 AM
> > 
> >     Subject: [Dataperf] Text Field in Reports
> annoyance...
> > 
> >      
> > 
> >     Hi Everyone,
> > 
> >      
> > 
> >     I have been putting up with a minor annoyance in
> DP
> > reports for some time as it has always seemed too hard
> to
> > rectify; if it can be rectified.
> > 
> >      
> > 
> >     When using a Text Field AxAy in a Report, when you
> > insert the field with the F4 Key it inserts the field
> format
> > as AyA0 (where y is the width of the field in the
> panel.) 
> > The A0 part basically says output all of the
> field's
> > data, irrespective of how many lines it takes.  If you
> want
> > fine control you can change the AyA0 to say AyA1 which
> > outputs only the first line but keeps the position
> counter
> > at the beginning of the next line, if you then output
> the
> > same field again with AyA1 it outputs the next line,
> and
> > repositions the output counter to the next line. You
> can use
> > other numbers other 1 to output the next n lines. It
> is only
> > when you format an AxA0 to output the balance of the
> field,
> > or use the Print Mode Indicator ;;N does the position
> > counter reset itself back to the beginning of the
> field.  It
> > generally provides all the control I need. I might
> have
> > missed something because this doesn't actually
> help my
> > problem, although I suspected that there might be some
> > manipulation that would
> > 
> >      
> > 
> >     The output I usually want from DP is XML or XHTML.
> > Generally to use the data, just in case there are XML
> > entities lurking in the data, I often would use
> AxA0;;W (The
> > ;;W print mode indicator changes the entities to valid
> XML
> > eg < becomes &lt; etc. On occasions my AxAy
> fields
> > are actually filled with HTML data which I can render
> in a
> > browser so I do not want to use the ;;W. At other
> times I do
> > not want the content to be parsed by an XML processor
> at
> > all, and so you do that in XML by wrapping the data in
> a
> > CDATA section. 
> > 
> >      
> > 
> >     An example of an XML element with a CDATA section
> is
> > this
> > 
> >      
> > 
> >     <myhtml><![CDATA[<br> This is some
> data
> > inside a CDATA section.
> > 
> >     The <u>Quick</u> Brown fox jumps over
> the
> > lazy dog]]>
> > 
> >     </myhtml>
> > 
> >      
> > 
> >     Lets say I output this from DP like this
> > 
> >      
> > 
> >     <myhtml><!CDATA[##########]]>
> > 
> >     </myhtml>
> > 
> >      
> > 
> >     Where ######## is an AxA0 field instead of what I
> > wanted I would have gotten
> > 
> >      
> > 
> >     <myhtml><![CDATA[<br> This is some
> data
> > inside a CDATA section.]]>
> > 
> >     The <u>Quick</u> Brown fox jumps over
> the
> > lazy dog
> > 
> >     </myhtml>
> > 
> >      
> > 
> >     ie the CDATA section is closed off at the end of
> the
> > first line instead of after the last line, and this is
> > altogether different from what I require. (This can be
> areal
> > gotcha as in the example I have just done it would
> still be
> > well formed XML and so you would not get any
> indication from
> > the XML Processor (eg browser) that something was not
> right
> > 
> >      
> > 
> >     Alternatively, which is my workaround, I can
> output
> > from DP like this:
> > 
> >     <myhtml><!CDATA[##########
> > 
> >     ]]>
> > 
> >     </myhtml>
> > 
> >      
> > 
> >     ie putting the closing of the CDATA section on a
> new
> > line, and although this gives me the generally correct
> XML
> > result, it inserts an extra CR after the data and
> before the
> > closing of the CDATA section. 
> > 
> >      
> > 
> >     <myhtml><![CDATA[<br> This is some
> data
> > inside a CDATA section.
> > 
> >     The <u>Quick</u> Brown fox jumps over
> the
> > lazy dog
> > 
> >     ]]>
> > 
> >     </myhtml>
> > 
> >      
> > 
> >      
> > 
> >     Usually the extra CR is no problem, and is just an
> > annoyance, but there are other times when it can
> interfere
> > with the results I want.
> > 
> >      
> > 
> >     If I could guarantee that the HTML content was
> actually
> > well formed XHTML I might not need to use the CDATA at
> all
> > and the extra CR would not be an issue, but I cannot
> > guarantee that, so I need another way.  
> > 
> >      
> > 
> >     Basically I would like to get the closing  ]]> 
> to
> > be appended immediately after the last bit of data
> from the
> > DP Text field on the same line. It is rare that I
> can't
> > get DP to deliver exactly what I want and it is giving
> me
> > the @#$%s that I haven't found an elegant way of
> doing
> > it.
> > 
> >      
> > 
> >     I am sure the same need to output text on the same
> line
> > after the last character in a AxAy field, occurs in
> other
> > applications, so I am hoping that someone has come up
> with a
> > solution
> > 
> >      
> > 
> >     Regards
> > 
> >     Brian
> > 
> >      
> > 
> > 
> >
> ----------------------------------------------------------------------------
> > 
> >     _______________________________________________
> >     Dataperf mailing list
> >     [email protected]
> >    
> http://lists.dataperfect.nl/mailman/listinfo/dataperf
> > 
> > 
> > 
> >
> ----------------------------------------------------------------------------
> --
> > 
> > 
> >   _______________________________________________
> >   Dataperf mailing list
> >   [email protected]
> >  
> http://lists.dataperfect.nl/mailman/listinfo/dataperf
> > _______________________________________________
> > Dataperf mailing list
> > [email protected]
> > http://lists.dataperfect.nl/mailman/listinfo/dataperf
> 
> 
>       
> _______________________________________________
> Dataperf mailing list
> [email protected]
> http://lists.dataperfect.nl/mailman/listinfo/dataperf
> 
> _______________________________________________
> Dataperf mailing list
> [email protected]
> http://lists.dataperfect.nl/mailman/listinfo/dataperf



_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf

Reply via email to