SCardTransmit() always return 6d00 - iphone

I'm trying to read name, card number, expiry date etc on Credit Card. but always return 6d00 when call SCardTransmit.
I'm using pre-define AID, which i have googled to be valid (correct me if i'm wrong). here's the are :
AID_LIST = {
"A0000000421010",
"A0000000422010",
"A0000000031010",
"A0000000032010",
"A0000000041010",
"A0000000042010",
"A00000006900",
"A0000001850002"
}
Thanks in advance.

I am not familiar with this API you are using, but you will have to send the following sequence of APDU commands:
SELECT PSE (for contact card), specified by EMV in Book 1, 11.3. An example is "00A404000E315041592E5359532E444446303100"
With the SFI returned, you can read the records to find out the supported AIDs. But, you can do this by "trial and error" using the pre-defineds AID that you specified and call SELECT AID, following the guidelines on Book 1, 12.3.3.
You may either call the command "GET PROCESSING OPTIONS" to see what records are available to read or you can read all possible records calling the "READ RECORD" command making a scan of the possible records. In one of those records, you will have the data you are looking for.
Usually in the same record you will have stored the Cardholder name, PAN and Track 2 discretionary data (in which is contained the expiration date).
The tags are listed in Book 3.
Application Primary Account Number (PAN) - 5A
Cardholder name - 5F20
Track 2 Discretionary Data - 9F20
Usefull info about Track 2:
http://en.wikipedia.org/wiki/Magnetic_stripe_card
A sample of the sequence above:
http://code.google.com/p/javaemvreader/wiki/ExampleOutput
EMV Specs:
http://www.emvco.com/specifications.aspx?id=223
The possible return codes, such as 61XX, 9000, etc are listed in ISO 7816. Here's a good overview: http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx

You need to lookup/buy ISO 7816, the EMV specifications and your vendors card specifications otherwise you don't know what you are doing.

Related

Access: Adding records with identical data, except for ID

I would like to be upfront. I am by no means an expert or even really all that technologically savy. However, I inherited a training system where the only way to find out if someone was current was to dig through physical file cabinets and try to find the hard copy. I have put together a basic access database to try and improve the situation. It is working okay, but I've run into a problem.
Previously, most training occurred in small enough batches that data entry is not a problem. (No more than 15-20 entries at any one time). However, regulatory changes now mandate the company put everyone through a mandated training course annually. This means all information about the training will be identical, except for the employee ID associated with the record.
Right now I can manually enter this training just like any other, but I have to perform this nearly identical data entry for each of the several hundred employees in the company.
I would like to be able to enter the pertinent details about the training and then have access create an training record for each employee.
The current form asks the user:
Who is the employee that was trained? (The appropriate employee ID # is entered)
Which subject was trained on? (the appropriate selection is made via combo box)
On what date was the training completed? Date picker is used to fill.
What is the file path to the scanned training certificate? (The majority of this field is prepopulated so only the actual file name needs to be typed. For the specific training in question all the employees of the company will be included in the same scanned pdf. Subsequently, this filed will be identical for all employees.)
The fields on the current form are:
txtEmpID – Text box, where employee ID # is entered. Corresponds to
field "empID"
cboTask – Combo box, where the appropriate training
subject is selected. Corresponds to field "reqID"
txtDate – Text box, the date the training was completed.
Corresponds to field "trngDate"
txtFilePath – Text box, file path to the scanned pdf of the physical
training record. Corresponds to field "trngLocat"
I would like to be able to fill in the information for 2-4 but then have access create a record, for each employee in my employees table, where all the data from 2-4 is identical.
Is this possible?
Pertinent Tables:
tblEmployees – keyed on field “empID” which is the employee number.
tblTrngSubjects - Keyed on field "reqID" which is autonumber.
tblTrngRec – keyed on field “recordID” which is autonumber. Relates
to tblEmployees through field “empID”. Relates to tblTrngSubjects
through field "reqID".
tblTrngRec is the table in which the records will be stored.
Other information that may be relevant:
I am using Access 2016.
I once had a copy of Access 2010 the missing manual…but that was in 2010. It has been almost a decade since I did anything more advanced than “docmd.openform”
I greatly appreciate any and all advice. Thanks, in advance.
I admit I haven't worked with access in quite some time, so some of the syntax might be slightly off. You need to know a list of employee IDs that were in that training.
Insert into tblTrngRec(empID,ReqID,txtDate,txtFilePath)
select empID
,25 'You need to enter this manually
,"6/9/2020" 'You need to enter this manually
,"Enter your file path"
from tblEmployees
where EmpID IN (enter a comma delimited list of employee IDs)

Use form to create multiple fields in Access 2010

So I have a form I have Vendors fill out when they want to ship to us. It's an excel form that I then import into Access so I can run reports. Sometimes when they send the form back it's in a format in which I have to manually enter the data into our database.
The form looks like this:
The middle section is just for example purposes so it's a rectangle with text in it.
So everything seemed simple enough until I got to the middle section. See in my excel form I have a section for multiple PO's and units. So essentially each shipment can have one to many PO's and Units. Currently I can approach this task with the redundant method of reentering information per PO on the form. But I want to make this simple.
So the task at hand is that I want to have a form field for PO's and Units where I can input multiple lines of information so that when I hit a submit button. It appears in the database on separate lines with the same vendor information.
So if I filled out my form had this in the middle section:
PO | Units
111111 22
222222 33
333333 44
When I hit submit I want it to attach the rest of the forms information to each PO on separate lines so it'd be like:
Vendor | City | State | PO | Units
Nike Memphis TN 111111 22
Nike Memphis TN 222222 33
Nike Memphis TN 333333 44
So how would I go about accomplishing this task?
From your description of the problem and your example of how the data appears to ultimately be stored in Access it looks to me like you are using Access as a spreadsheet and not as a database. This is ok, but you might want to consider normalizing the data to take advantage of the power of databases in general.
For example:
Create a Vendors table whose sole purpose is to keep details about each Vendor you work with. A very basic implementation would have an ID field to uniquely identify each vendor and a Name field for the vendor name.
If Vendors will only ever have a single location you could also store City, State, ZipCode and Email in this same Vendor table, but I suspect having a separate VendorLocation or VendorAddress table would be a better fit long term.
Create a VendorShipment table that tracks the higher level information on your mockup, such as:
ShipmentID (primary key of this table)
VendorID (foreign key back to Vendor table)
Ready Date
Carrier
Estimated Cost
FreightClass
Tracking #
Estimated Transit Time
Finally, create a VendorShipmentDetail table that tracks the information of each shipment, including:
ShipmentDetailID (primary key of this table)
ShipmentID (foreign key back to VendorShipment table)
PO
Units
Any other details that you want to or need to track
Organizing and storing the data in a normalized fashion would ultimately help simplify your data entry \ data management process and potentially make for a better user experience.
For example, rather than having to enter the Vendor Name, Address information, etc. each time you could instead use a combo box control that is tied to the Vendor table. If the Vendor exists in the table you select it from the list and you already have the Address information, no need to re-enter it each time. If the Vendor did not already exist you enter it once (probably on a Vendor screen where you maintain the details for each Vendor) and draw upon the information in the future.
You would then use queries to tie the information back together for reporting purposes (de-normalize the information).
The art of database design can take a while to pick up, but a good starting point might be to check out the Northwind database that Microsoft has maintained over the years. It has some examples you could draw from immediately to get a practical understanding of how to use normalization within Access. You can find more information here: http://office.microsoft.com/en-us/templates/northwind-sales-web-database-TC101114818.aspx

Yodlee - Retrieving bank data in the US but "tranListFromDate" and "tranListToDate" properties are null

I am using Yodlee to retrieve bank account transaction details for a real-world US bank.
I am retrieving a lot of transaction data, but I was surprised to see the "transListFromDate" and "tranListToDate" properties of the BankData class have a NULL value for both of them.
I am wondering if these are always NULL for all "bank" containers/sites supported by Yodlee, or if this is just an issue with this particular bank.
If these date fields ARE populated with some banks, can anyone supply me with details (possibly sample sample values) about these related properties for these particular dates?
displayTimeZone (string)
localFormat (string)
timezone (string)
Thanks in advance!
Eden, these data elements are usually not set.
"transListFromDate" indicates the "Transaction From date" and "tranListToDate" indicates the "Transaction to date" used during the last refresh attempt respectively and hence is of no much significance. It does not represent the complete transaction duration range that the user has.

Keeping a long-term reference to an IOS AddressBook entry

Given that an ABRecordID can change between cloud syncs and under other circumstances out of my control, how can I maintain a long-term reference to an IOS address book record?
Apple provides the following guidance:
"The recommended way to keep a long-term reference to a particular record is to store the first and last name, or a hash of the first and last name, in addition to the identifier. When you look up a record by ID, compare the record’s name to your stored name. If they don’t match, use the stored name to find the record, and store the new ID for the record."
But I don't understand this guidance. If the address book can have duplicate names in it AND since users can modify the name in a record how could this advice work?
For example, if the user modifies the name of an address book record my routine will fail to find it by ABRecordID so if I think search by the name hash I stored couldn't I find a duplicate name instead of the new ABRecordID for that specific record I previously referenced?
In the end, what is the BEST way to get a long-term reference to an IOS AddressBook record? And if the above advice really does work what am I missing?
The most robust (yet not completely failsafe) approach would be to come up with a priority ranking of ABRecord fields and store as much from that list as is available, along with the ABRecordID, into your own (hashed) private record format. When retrieving a private record (or at another convenient time), you can verify that the private record matches the ABRecord and work through a series of fallback checks to ensure it's accurate.
Example priority ranking:
ABRecordID
FirstName
LastName
PhoneNumber
ZipCode
When retrieving a record you can first match the ABRecordID. If that returns no results, you can do a search for FirstName + LastName. You can then match those results against PhoneNumber... etc. In this way you could potentially distinguish between 2 Bob Smiths, as they may have different phone numbers (or one may not have a phone number). Of course, depending on how long your priority list is, the more robust this mechanism will be.
The last resort would be prompting the user to distinguish between 2 Bob Smiths with brand new ABRecordID's whose records are otherwise identical -- after all, such an inconvenient prompt would be far more friendly than allowing the User to contact the wrong Bob Smith (and as I said, would be a last resort).
This solution for AB may involve some synchronization issues, however.
This is a familiar problem for anyone who has worked with the iOS Media Player. Specifically MPMediaItems in the User's Music Library have a property MPMediaItemPropertyPersistentID which the docs describe as:
The value is not guaranteed to persist across a sync/unsync/sync cycle.
In other words, the PersistentID is not guaranteed to be persistent. Solutions for this include doing similar fallback checks on MediaItem properties.
The RecordID only get changed either on delete or reset, when this is done all the new record(s) will have new createdProperty and modifiedProperty as well.
While I am reading the address book for the first time, I will save all entries of the record along with RecordID in my database.
I will save the last time the contacts synced from contacts to my database(name it something: lastSyncedTime) and store it some where.
I am done with syncing the contacts for the first time, now do the following for syncing anytime in future.
while Iterating through all records,
check createdTime(kABPersonCreationDateProperty) vs lastSyncedTime. If createdTime > lastSyncedTime, store the recordID in a "newRecords" NSArray.
If !(step 1) then check modifiedDate(kABPersonModificationDateProperty) vs lastSyncedTime. If modifiedDate > lastSyncedTime, then store the recordID in a "modifiedRecords" NSArray.
if !(1) && !(2) store all recordID in a "unModifiedRecords".
Now I will read all the contacts from my local database,
I will delete all local database records that are not find either in "modifiedRecords" or in "unModifiedRecords".
I will update all "modifiedRecords" in the local database.
I will create new records for all records in "newRecords".
Update the lastSyncedTime accordingly.
The documentation is communicating to you that you can't count on ABRecordID as a permanent identifier.
Consider this scenario: The user has a record for "Bob Smith". The user then deletes his "Bob Smith" record and then imports his contacts from his computer (creating a new ID) through iTunes sync.
So if you want to keep a permanent reference to an existing contact, you can keep a reference to the name and id as a hint that it is the same record you used before- but there is no real permanent reference.
If you keep a permanent reference to an address book contact, you must always be ready to deal with the fact that it may not be the same contact you used before.
Refer :
https://developer.apple.com/library/ios/documentation/ContactData/Conceptual/AddressBookProgrammingGuideforiPhone/Chapters/DirectInteraction.html#//apple_ref/doc/uid/TP40007744-CH6-SW2
Clearly tells you how to handle it.

What is the correct way to associate with a ABPerson?

In many of my apps, it requires associating some data with a contact in addressbook. What I used to do is save the record id of an ABPerson and use that id to pull information upon each app launch. However, more and more I find that this approach is wrong because many times a user will use a service like mobileme where the addressbook is wiped and resynced. This causes the record id to change and all associations are lost. The user will have to go through each one and re-link them.
What is a better approach to holding a robust pointer to addressbook entries?
You should store three values: the record ID, the first name, and the last name.
1) In the case that the record ID hasn't changed, you're golden - just use that to locate the proper record.
2) If ABAddressBookGetPersonWithRecordID() does not locate a record for your stored record ID (it returns NULL), then you'll need to search the person records for a match based on the first and last name. You can drop down to using ABAddressBookCopyPeopleWithName() potentially or write your own locating code if you already have an array with all the person records in-memory. Locating the new record is up to you. Once to locate the new record, you can update your data storage with the new record ID.
Ultimately, you end up storing the record ID to use directly incase it doesn't change (if you're lucky) plus storing some keys from the address book entry that are unlikely to change. The name of the person or organization associated with an address book entry is most likely to change. You should, of course, account for the case where you may not find a record with the stored record ID or by searching for the name. This could trivially mean that the record was deleted, or it could mean that the record was renamed. You should handle that case whichever way you decide is best for your specific application.
I know this was last year, however, I thought I might suggest a method I use. The first time I ask the user to pick a contact (in order to associate certain of my app's private data with it) I then grab the record, create my own internal record id (the initials of the app name and a sequence number usually) modify the contact by adding a new ABRelatedName (type of "pref" name of "Other") value of my own internal record id. It looks like this in the .vcf
item3.X-ABRELATEDNAMES;type=pref:BZA101
item3.X-ABLabel:_$!<Other>!$_
That way, I can simply reference that record id when i add more data about the user such as the last time the app user contacted them, etc. Seems to work for me.
Hope that helps someone.
If the address book is indeed being completely wiped and re-loaded, and the only part that doesn't change is the display name, then storing the display name as the link seems like the only option.