Datetime Fields vs. Timestamps: What's the Difference?
The word "timestamp" gets used loosely, so it helps to be precise. There are two different types of fields you might use to track changes in Rapidi.
Datetime fields are human-readable. They show a specific date and time, for example when a record was created or last updated. Any user can look at a datetime field and understand what it means straight away.
Row version fields are different. These are system-generated integers that track every new or updated record as a sequence number. You'll see these in older systems like Microsoft Dynamics. The number itself has no date meaning. You can't convert it to a date and time. It just tells you that a new record exists, or that something changed.
Both types can work as source control in Rapidi, but the format you see stored in the RTI will depend on which one you're using.
Before You Do Anything: Index the Field
Whatever field you plan to use as source control must be indexed in your source system. This is not optional. When Rapidi runs a transfer, it queries your source system based on that field. If the field isn't indexed, performance suffers and you put unnecessary load on the system.
In some systems, like Microsoft Business Central, the field also needs to be published and deployed before you can query it. The system timestamp field exists in Business Central, but it's not available on the page by default. End users can't see it, and Rapidi can't access it until it's published. Once it's deployed to your production environment, the field becomes available for filtering and you can use it as source control.
Good to know
In Business Central, the timestamp field is a system field. It exists, but it's not published on the page by default. You need to deploy it to your production environment before Rapidi can use it.
What Is the RTI?
RTI stands for Runtime Information. Think of it as Rapidi's internal reference book for your transfers. Every time a transfer runs successfully with source control enabled, Rapidi writes an entry to the RTI. That entry records the highest value of the source control field at the time of the run.
The next time the transfer runs, Rapidi checks the RTI, finds that stored value, and queries your source system for records where the source control field is greater than that value. That's how it knows what changed.
A few things to know about RTI entries:
- An RTI entry only exists if source control is enabled on the transfer.
- If you've never run the transfer, there's no RTI entry. It gets created on the first successful run.
- Each RTI entry is unique, identified by a combination of the transfer code, source system, and destination system.
- If a transfer fails, the RTI does not move forward. Rapidi will retry from the same point on the next run, so nothing gets skipped.
The value stored in the RTI is in Unix format, regardless of whether you're using a datetime field or a row version. If you want to convert a stored Unix value back to a readable date, you can use any Unix timestamp converter online.
A Practical Example
Here's how this looks in practice with two transfer runs 30 minutes apart.
Example: Two runs, 30 minutes apart
10:00 AM
Transfer runs successfully. Rapidi reads all records, captures the highest source control value, and stores it in the RTI.
10:30 AM
Transfer runs again. Rapidi checks the RTI, finds the 10:00 AM value, and queries the source for records where the source control field is greater than that value. If records were created or updated in that half hour, Rapidi pulls them. If nothing changed, nothing gets transferred.
This is exactly why source control matters. Without it, every run queries the full table. With it, only the delta gets pulled.
How to Reset the RTI
There are two situations where you might want to manually change the RTI value.
Full re-sync: Set the source control value in the RTI to zero. The next run will query for all records where the source control field is greater than zero, which means everything. Use this if you need to bring all data over to the destination system from scratch.
Re-run from a specific point: Edit the source control field in the RTI to a specific value. The next run will pull records from that point onwards. This is useful if something went wrong and you need to re-transfer data from a particular date or sequence number.
Both options are available on the RTI page in Rapidi. You can get there from the main navigation at the top, or directly from the transfer using the RTI icon. Either way works.
The One Rule to Follow
Key takeaway
Never run a transfer without source control.
Without it, every run queries your entire source table, every time. That creates unnecessary load on the source system and slows everything down. With source control enabled and the field properly indexed, transfers run faster, and your source system doesn't take a hit.
Set it up correctly once, and the RTI handles the rest automatically.
