headers
David Dancy | 1 Sep 2010 01:05
Picon

Re: Keeping 4D In Background

I'll see what I can do.

David Dancy
Sydney, Australia

On 1 September 2010 01:51, Cannon Smith
<cannon@...> wrote:
> Hi David,
>
> I'd like to give this a try. Do you happen to have a Mac stub for the plugin so I can compile for both platforms?
**********************************************************************
Don't miss it - savings up to $200 for the 4D Summit ends today!
http://www.4d.com/company/events/summit2010.html

4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
**********************************************************************
Permalink | Reply | 1 comment |
headers
David Dancy | 1 Sep 2010 01:13
Picon

Re: How do I do this in SQL? Or do I do it in SQL?

Use an extra field!

Have one number as your primary key for referential integrity (which
can be out of order and the sequence can have holes in it). Users
never see this number.

Just prior to validating the transaction get your real packing slip
number and store that in a different field. This is the field that you
present to users.
You can even assign it in the save trigger for the table.

Doing it this way should guarantee no holes in your packing slip
sequence and no need to put back unused numbers onto a stack.

HTH

David Dancy
Sydney, Australia

On 1 September 2010 06:27, Michael Cook <myklcook@...> wrote:
> I just found a problem and I'm not sure how to solve it and I'm looking for
> ideas.
>
> We have two DB's that talk to each other using SQL. Db1 creates a packing
> slip in Db2.
>
> Packing Slip numbers in Db2 must be sequential. Can't burn a number.
**********************************************************************
Don't miss it - savings up to $200 for the 4D Summit ends today!
http://www.4d.com/company/events/summit2010.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cannon Smith | 1 Sep 2010 01:19

Re: Keeping 4D In Background

Thanks. No rush, just if you get time.

--
Cannon Smith
Synergy Farm Solutions
P.O. Box 65 -- Hill Spring, AB CANADA -- T0K 1E0
(403) 626-3236 or 1-866-626-3236
<cannon@...>
<www.synergyfarmsolutions.com>

David Dancy wrote:

> I'll see what I can do.

**********************************************************************
Don't miss it - savings up to $200 for the 4D Summit ends today!
http://www.4d.com/company/events/summit2010.html

4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
**********************************************************************
Permalink | Reply | 0 comments |
headers
Peter Jakobsson | 1 Sep 2010 01:20

Char(186)=Char(111). Why ?

Hi Folks

I thought I understood character encoding.

I think again.

I now think I don't understand it. Also, my 'blindspot' on this  
subject seems to get bigger every day.

Recently I discovered some (string) 'Find In Arrays' that weren't  
finding the character they were supposed to if there were non-ascii  
values in the strings. (e.g. Find in Array("o") would not find the 'o'  
even if it was there - it would however find a high-ascii degree sign  
who's Character Code=186.

I now find that equivalence tests like this Char(186)=Char(111) return  
true - even if the characters render differently.

What I thought would happen is that 4D internally stores Char(186) as  
a 2-byte integer who's decimal value is 186 and Char(111) similarly.  
When they are compared it would compare the 2 2-byte values and find  
them to be different.

Can any unicode scholars tell me what's going on here ?

Regards

Peter

**********************************************************************
(Continue reading)

Permalink | Reply | 9 comments |
headers
David Dancy | 1 Sep 2010 02:17
Picon

Re: Char(186)=Char(111). Why ?

Char(186) is a string, as is Char(111). It is therefore subject to the
Unicode string comparison rules. These are quite complicated.

I looked up the 2 characters concerned, and found this:

Char(111) (0x006F) is LATIN SMALL LETTER o
Char(186) (0x00BA) is MASCULINE ORDINAL INDICATOR (Spanish)

A small note against the Char(186) says "similar to <super> 006F".

I think this means that 4D is correct: a superscripted LATIN SMALL
LETTER o can be treated as being the same as MASCULINE ORDINAL
INDICATOR. But since in 4D there's no such thing as a superscript the
comparison ignores the variation and says they are equal. In a text
environment (like Microsoft Word) where superscripts are meaningful
the comparison would quite likely say they are not equal.

If you really have to tell them apart, you'll need to make your
strings compare by character codes, using things like
Position($Find;$Lookin;$Start;$LengthFound;*) or some mechanism you
invent yourself.

The * tells 4D to compare character codes, not strings.

If you want Find in array() to do byte comparison you'll have to
create a wrapper command of your own that uses Position(...;*) on each
element to determine if elements are equal to your find text.

As an alternative to Position(...;*) you could use Match regex().
(Continue reading)

Permalink | Reply | 8 comments |
headers
Peter Lerch | 1 Sep 2010 02:28
Picon
Favicon

Re: Updating Resources... v11.6


Michael Cook-4 wrote:
> 
> Your method of deleting the 4DIndy file works.
> 

It does not work always for compiled applications. I never include the
4DIndy file in the server build.

Peter
--

-- 
View this message in context: http://4d.1045681.n5.nabble.com/Updating-Resources-v11-6-tp2653007p2798820.html
Sent from the 4D Tech mailing list archive at Nabble.com.
**********************************************************************
Don't miss it - savings up to $200 for the 4D Summit ends today!
http://www.4d.com/company/events/summit2010.html

4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
**********************************************************************
Permalink | Reply | 0 comments |
headers
Peter Jakobsson | 1 Sep 2010 08:12

Re: Char(186)=Char(111). Why ?

Hi David

Thanks for that extremely comprehensive answer.

That explains it and I now remember that in Unicode string evaluations  
mean 'roughly equals' rather than 'actually equals'.

It would be useful if 4D supported string comparisons using character  
codes (* parameter). (For example, find in array now breaks for some  
things since characters are effectively no longer unique). Maybe it  
wouldn't.

I need to think about this ~  ? zzz

Thanks again

Peter

On 1 Sep 2010, at 02:17, David Dancy wrote:

> f you really have to tell them apart, you'll need to make your
> strings compare by character codes

**********************************************************************
Don't miss it - savings up to $200 for the 4D Summit ends today!
http://www.4d.com/company/events/summit2010.html

4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
(Continue reading)

Permalink | Reply | 7 comments |
headers
DevTeam | 1 Sep 2010 09:19

Re: Char(186)=Char(111). Why ?

This is very interesting.

What would happen if these characters were in an indexed field with the "unique" attribute?

I haven't specifically tried that but if 4D uses this type of comparison internally, this may be the tip of
the iceberg of some other Unicode issues. Perhaps a MAJOR GOTCHA?

-- 

François Tiffreau

IT Manager

ESL iLab
Head office – Switzerland:
Grand-Rue 50, CH-1820 Montreux
t  +41 21 962 88 80
f  +41 21 962 88 81

http://www.esl-education.org

Please consider the environment before printing this e-mail

This e-mail message may contain certain confidential and privileged material for the sole use of the
intended recipient. Any review, use or distribution by others is prohibited. If you are not the intended
recipient, please contact the sender and destroy or delete all copies.

On 1 sept. 2010, at 08:12, Peter Jakobsson wrote:

> Hi David
(Continue reading)

Permalink | Reply | 6 comments |
headers
Peter Jakobsson | 1 Sep 2010 09:25

Re: Char(186)=Char(111). Why ?


On 1 Sep 2010, at 09:19, DevTeam wrote:

> What would happen if these characters were in an indexed field with  
> the "unique" attribute?

Easy to try.

**********************************************************************
Don't miss it - savings up to $200 for the 4D Summit ends today!
http://www.4d.com/company/events/summit2010.html

4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
**********************************************************************
Permalink | Reply | 0 comments |
headers
Jörg Knebel | 1 Sep 2010 10:08
Picon

v12 documentation in PDF

Hi,

Where can I find the documentation for v12 in PDF-format?

Thanks.

Regards
Jörg Knebel - 4D Developer since 1991
TTT Data Systems Pty Ltd
Phone: +61 (0)2 6334 4730
www.tttdatasystems.com.au

**********************************************************************
Don't miss it - savings up to $200 for the 4D Summit ends today!
http://www.4d.com/company/events/summit2010.html

4D Internet Users Group (4D iNUG)
FAQ:  http://lists.4d.com/faqnug.html
Archive:  http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub:  mailto:4D_Tech-Unsubscribe@...
**********************************************************************
Permalink | Reply | 1 comment |

Gmane