On Aug 4, 2017, at 1:25 PM, Timothy Penner via 4D_Tech <4d_tech@lists.4d.com>
wrote:
> For this specific issue, I wonder if the behavior is mentioned in the
> references to "custom mode" in the 'External Data Storage' documentation here;
>
Hi,
> Would the livedoc version get the information into the docs for all supported
> versions of the product?
I believe public comments carry over to all versions that article is used by.
For example, this comment made on August 2015 is visible for v14:
-
Working with V15.
The definition script for SQL for a few fields is ‘bigint (18)’.
If I specify a 64 bit integer, I get negative numbers upon import. No
calculations are done with the numbers, so should I define them as alpha fields?
_
Bob McKeever
Would the livedoc version get the information into the docs for all
supported versions of the product? If so, it sounds like John could write
it up. Otherwise, what do you have to do - file a doc bug? Is that a thing
at 4D?
**
4D
Hi David,
> Not sure how that happens, but I know that there's a way if you log in to
> something, somewhere, somehow...Or 4D could add something to the docs.
Do you mean this?
Tech Tip: The Comments feature for the Documentation Site .
http://kb.4d.com/assetid=77724
-Tim
John,
It's great that you found this and tracked down the solution within a day,
with help from 4D.
Since this sounds like a potentially painful gotcha, it would be great if
the docs were updated with some notes. Not sure how that happens, but I
know that there's a way if you log in to
+2
Nigel Greenlee
> On 4 Aug 2017, at 12:09, Marcus Straßmann via 4D_Tech <4d_tech@lists.4d.com>
> wrote:
>
> +1
>
>
> MacStrass - Marcus Straßmann
> Softwareentwicklung und Beratung
> Auf der Markscheide 35
> D-44807 Bochum
>
> Mobil: +49 (173) 374 39 92
> eMail: macstr...@macstrass.de
>
Kirk,
Correct me if I am wrong but, there is no choice with external data and
client server as the external data folder is on the server machine. The
managing of the external file has to be done on the server and a trigger is the
logical place to do it as the external file has to be
+1
MacStrass - Marcus Straßmann
Softwareentwicklung und Beratung
Auf der Markscheide 35
D-44807 Bochum
Mobil: +49 (173) 374 39 92
eMail: macstr...@macstrass.de
Am 04.08.2017 um 10:39 schrieb Herr Alexander Heintz via 4D_Tech
<4d_tech@lists.4d.com>:
>> Someone can explain when is better use
John,
On Fri, Aug 4, 2017 at 1:36 AM, John Baughman via 4D_Tech <
4d_tech@lists.4d.com> wrote:
> 3. Click the save button. The table trigger’s on saving new record event
> does the following...
> a. Saves the picture to my documents folder with WRITE PICTURE FILE
> b. Sets the
I'll add my vote to Jody's approach.
I prefer UUIDs for primary keys for all the reasons mentioned.
Having a longint index field is useful as well but for different reasons as
Jody explains. My most common use is to be able to quickly sort a table in
the order records were created. And it is
So what might be not so good with UUIDs?
After watching how people work with our systems for 26 years (most of it
without UUID capability) I noticed that they often referred to the record by
the Unique LongInt we created for each record. For the first year we hid our
unique ID - why would
> I can’t speak to any performance differences when using them as indexed key
> fields for searches … they likely have similar performance, but that’s just a
> guess.
I can speak to the performance, they are not the same. UUID is faster.
4D uses BTrees (binary trees or sometimes called
what happens if you do
[myTable]myPicture:=[myTable]myPicture*0
before you load the new jpg ?
your trigger is running, so the picture is touched for the database, we can
assume that.
but the picture on form is not updated, so it sounds like a ref count issue for
the form.
besides, you
> OK. I got my hand slapped for posting a bug to the beta forum.
I apologize for my bad English or being unclear in my answer.
I only wanted to help you to speed up the process, as getting solutions for
issues is - in my experience - faster using the 4D Partner support directly, as
the team is
I can’t speak to any performance differences when using them as indexed key
fields for searches … they likely have similar performance, but that’s just a
guess.
But here’s one situation where UUID has an advantage. We historically used the
Sequence Number (a longint) as the primary key, until
OK. I got my hand slapped for posting a bug to the beta forum. Somewhat miffed,
I created a test db in v16.1 so I can either prove it to be a beta bug, or be
able to talk to 4D TS in the morning with a version other than the beta. Well I
am having the same problem in v16.1. So, yes I erred by
Hi All,
Someone can explain when is better use UUID and when Longint field in
primary key?
Thanks
Ferdinando
**
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive:
18 matches
Mail list logo
