Jump to content
Server Maintenance This Week. ×

Internally FileMaker has a date value as an integer....


HappyCab

This topic is 3529 days old. Please don't post here. Open a new topic instead.

Recommended Posts

I am now an intermediate BEGINNER Filemaker user. (1 month as of SEPT 2014)

 

I heard that internally Filemaker understands the DATE VALUE as an INTEGER (whole number) that starts at 1 from the year 1/1/0001

 

I have multiple tables that relate primarily on the date...

 

 

 

QUESTION 1

Is there a way to see this number?

 

 

 

QUESTION 2

Should I Not Use DATE fields as KEYs in my relationships ?  

The relationships seem to be working fine, but this is early in my solution and fear I may get into trouble??

 

 

 

POSSIBLE SOLUTION ::

Make an Auto INCREMENT serial number field and then match on those?

 

..then How do I ensure date sequence and a separate serial number increment field are properly SYNCHRONIZED should they ever become miss sorted and new records later added.

 

Any suggestions..or referrals to others posts I have missed are appreciated in advance.

 

Respectfully, 

 

HappyCab

Link to comment
Share on other sites

I am now an intermediate BEGINNER Filemaker user. (1 month as of SEPT 2014)

 

I heard that internally Filemaker understands the DATE VALUE as an INTEGER (whole number) that starts at 1 from the year 1/1/0001

 

I have multiple tables that relate primarily on the date...

 

 

 

QUESTION 1

Is there a way to see this number?

 

 

GetAsNumber( your date )

 

 

QUESTION 2

Should I Not Use DATE fields as KEYs in my relationships ?  

The relationships seem to be working fine, but this is early in my solution and fear I may get into trouble??

 

 

 

Unless you only happen to (ever!) only have one record per day then the date is not guaranteed to be unique.  Primary keys must be unique.

So always use an auto-increment serial or UUID.

 

The way you present your data to the user should not depend on the value of the primary key.  Simply sort the data like it should to make sense for the business case.

  • Like 1
Link to comment
Share on other sites

QUESTION 2

Should I Not Use DATE fields as KEYs in my relationships ?  

The relationships seem to be working fine, but this is early in my solution and fear I may get into trouble??

 

Hard to say without knowing what your tables and records represent and how these things are related in real life.

Link to comment
Share on other sites

GetAsNumber( your date )

 

Unless you only happen to (ever!) only have one record per day then the date is not guaranteed to be unique.  Primary keys must be unique.

So always use an auto-increment serial or UUID.

 

The way you present your data to the user should not depend on the value of the primary key.  Simply sort the data like it should to make sense for the business case.

 

Thank you for saying "The way you present your data to the user should not depend on the value of the primary key"

 

That makes sense and keep my thinking structured.

 

 

Ok...SO,

 

I tried out the GetAs ( Date )   and that IS what I was looking for.

 

 

For this situation....

 

EACH DATE DOES IN FACT REPRESENT A SEPARATE RECORD. (i wish I posted that originally...sorry 'bout that)

 

so... I never have 2 records for one date

 

 

Since each record WILL be unique, I think I might KEEP MATCHING on "DATE_field"

...because I fear I might mix up record sync between a date value sequence and a separate AUTO-Entered Calculated field

 

 

 

 

Also,  thank you "COMMENT Consultant"...that makes sense too.

 

 

Ok I appreciate everyone's time.

 

 

Respectfully,

 

Happycab

Link to comment
Share on other sites

This topic is 3529 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.