I'm using Outlook Redemption to write an algorithm that will synchronize SQL database w/ the contents of an email folder.
I'd like to track the emails in the database by Outlook EntryID, but the Microsoft documentation on EntryIDs mentions that one Email Item can have multiple EntryIDs. Under what conditions will an Email Item have more than one EntryID?
MAPI can refer to the same object using multiple entry ids. Exchange uses so called short-term entry ids (returned by the folder contents table) and long term entry ids (returned from the object itself). Short term entry ids can only be used in the session that returned them, hence they should not be persisted and used across MAPI sessions.
Related
I was looking at the Users API on the D2L API reference site:
http://docs.valence.desire2learn.com/res/user.html
And there does not appear to be a way to find a user by email address.
Is there a way to do this with the current API?
You can fetch user records from the .../users/ route using either the organization-defined ID, or the user login name properties. Additionally, you can fetch the user record for a user identified by the LMS UserID property. You cannot currently easily retrieve a user record based on another property in the user record: you'd need to fetch entire collection of users and then sort through for the record with the email address you're looking for. With most organizations, this is not at all ideal because of the number of users involved.
Generally improvements to the API of this nature are on the development roadmap, however there isn't a specifically deployment plan in place for an enhancement on this particular use-case. That said, enhancements to the routes to search for fundamental data objects (users, org units) are identified as having strong value by clients and that's a primary driver in determining priority for improvements..
We've an MVC web app which has a Claim management wizard (similar to a typical Order entry stuff). Claim can have multiple Items and each Item can have multiple files related to it.
Claim --> Items --> Files
While adding a new Claim - we want to allow the user to add one or more items to it and also allow file upload for those items. But we want to keep everything in memory until the Claim is actually saved - so that if the user doesn't complete the Claim entry or discards it, no database interaction is done.
We're able to handle data level in-memory management via session. We serialize the Claim object (which also includes a Claim.Items property) in session. But how to manage files?
We store files in < ClaimID >\< ItemID > folder but while creating a new
claim in memory we don't have any IDs until the record is being
saved in the database (both are auto-increment int).
For now, we've to restrict the user from uploading files until a Claim is saved.
Why not interact with the database? It sounds like you're intending to persist data between multiple requests to the application, and databases are good for that.
You don't have to persist it in the same tables or even in the same database instance as the more long-term persisted data. Maybe create tables or a database for "transient" data, or data that isn't intended to persist long-term until it reaches a certain state. Or perhaps store it in the same tables as the long-term data but otherwise track state to mark it as "incomplete" or in some other way transient.
You could have an off-line process which cleans up the old data from time to time. If deletes are costly on the long-term data tables then that would be a good reason to move the transient data to their own tables, optimized for lots of writes/deletes vs. lots of reads over time.
Alternatively, you could use a temporary ID for the in-memory objects to associate them with the files on the disk prior to be persisted to the database. Perhaps even separate the file-associating ID from the record's primary ID. (I'm assuming that you're using an auto-incrementing integer for the primary key and that's the ID you need to get from the database.)
For example, you could have another identifier on the record which is a Guid (uniqueidentifier in SQL) for the purpose of linking the record to a file on the disk. That way you can create the identifier in-memory and persist it to the database without needing to initially interact with the database to generate the ID. This also has the added benefit of being able to re-associate with different files or otherwise change that identifier as needed without messing with keys.
A Guid shouldn't be used as a primary key in many cases, so you probably don't want to go that route. But having a separate ID could do the trick.
I am working on PHP project that should fetch emails from IMAP server, and store them in local database.
Same IMAP server can be used by other email clients, like outbox and so on.
The problem is how to know which messages I already fetched, and which I didn't? I am thinking to use search by datetime, but is it reliable(I would have cronjob, that would access user mail box every minute, and check for emails, but not sure if datetime can cause some issues, for example in case when at almost same time arrive short message and message with big attachment).
I was thinking about system tags, but user can modify them via email client, so I can rely on them, and don't want to modify them and confuse client.
Next I was thinking about custom tags, but not all IMAP servers support them(and our software need to be flexible as much as possible).
Any good idea how I could solve this problem?
Keep track of the currently highest synced UID of the folder you are syncing, and verify that the UIDVALIDITY value of the folder match.
Unique identifiers are assigned in a strictly ascending fashion in the mailbox; as each message is added to the mailbox it is assigned a higher UID than the message(s) which were added previously. Unlike message sequence numbers, unique identifiers are not necessarily contiguous.
In my program I have multiple databases. One is fixed and cannot be changed, but there are also some others, the so called user databases.
I thought now I have to start for every database one connection and to connect to each data dictionary. How is it possible to connect to more than one database with one connection by handing over the data dictionary filename? Btw. I am using a local server.
thank you very much,
André
P.S.: Okay I might find the answer to my problem.
The Key word is CreateDDLink. The procedure is connecting to another data dictionary, but before a master dictionary has to be set.
Links may be what you are looking for as you indicated in the question. You can use the API or SQL to create a permanent link alias, or you can dynamically create links on the fly.
I would recomend reviewing this specific help file page: Using Tables from Multiple Data Dictionaries
for a permanent alias (using SQL) look at sp_createlink. You can either create the link to authenticate the current user or set up the link to authenticate as a specific user. Then use the link name in your SQL statements.
select * from linkname.tablename
Or dynamically you can use the following which will authenticate the current user:
select * from "..\dir\otherdd.add".table1
However, links are only available to SQL. If you want to use the table directly (i.e. via a TAdsTable component) you will need to create views. See KB 080519-2034. The KB mentions you can't post updates if the SQL statement for the view results in a static cursor, but you can get around that by creating triggers on the view.
There are many suggestions here and there for storing e-mail messages. Somehow what I am doing is writing an Outlook addin to send emails from inbox/sent folders directly to my application.
So only what is really interesting is saved. And I decide where to save it.
Imagine this case:
I recieve an email from a customer. It's up to me to decide whether I should save it on the customer or on the order 24 that that customer did. So this is why I am doing the add in, and not some automatic storing of emails = noise after some time.
This said, how to store the emails? For the emails that I recieve or send through Outlook the idea could be save the whole file in a blob field (so the eml file), may be I can save also other info (like the subject) in another text field. But the problem comes when I write an email from my application.
In this case I am not generating an eml file, I send through MAPI data to Outlook to compose an email that I will send with Outlook (so in this case I cannot save the eml), or I directly send it with Indy. Also in this case I don't have the eml file...
One idea could be that the all the emails that I auto compose have a special flag that the Add in recognises and therefore when I send the mail it is stored back to the DB. So in this case I can save the eml also of the mails I sent from my application.
May you comment?
First you have to decide on on what information you want to store. The rest is just a means to get there.
One option is to store the .msg files (you have posted related questions suggesting you are no stranger to MAPI) in stead of .eml files. Using MAPI you can store the IMessage you created as a .msg file (with a bit of pain). However, not all mapi props will be set until the message actually is sent, you so might need to hook outlooks send items folders for that.
A much more straightforward solution would be to generate the .eml (or whatever textbased format you prefer) directly from the source. When sending, take your source data, generate the correct MAPI calls to outlook AND generate the .eml and store it directly into your database. When recieving, have Outlook save to .eml directly.
Personally, I wouldn't use .eml at all for storage. I would parse the data I'm particularly interested in (like to/from addresses) into separate columns. In the end, you are probably using your DB for data retrieval. Databases tend to do a better job when you don't store everything in a single memo/blob field. :)