I am not finding how wide the transaction_Id string is when returned. I need to store that in a database and need to know how wide to set the column. I am not finding it in their documentation.
https://docs.connect.squareup.com/api/connect/v2/#endpoint-charge
https://docs.connect.squareup.com/api/connect/v2/#type-tendercashdetails
Currently most transaction_ids are 26 characters long, but there is no guarantee about how long, or what format an id would be. Some of Square's ids are 36 character GUIDs and that is probably a reasonable upper limit. My advice is to make your column at least 36 characters wide, and include logic in your app to check if a longer id is received that would be truncated in your table.
Related
using eloquent is it possible to save a numeric value like 012345 with the leading 0 or is the only possibility to store the value as string?
To provide more details: I'd like to store a zip-code, which can have a leading 0 in Germany. There's no possibility to always add the 0, because not all zips start with 0
Numeric datatypes do not retain leading zeros, as they are insignificant to the number you want to store. Char or Varchar is more appropriate. You could set a constraint to ensure only numeric characters are stored.
If you absolutely cannot change the data type, then another alternative is to store the number of leading zeros into another int field
So in your example you would store:
Value : 32
Leading zeros : 2
Source https://stackoverflow.com/a/23309167/5442966
012345 is not a number. It's a string. 12345 is the number. SQL Server is able to recognize that those extra zeros are not needed to define the number, so it ignores them. If you want to dispaly a value as 012345 to the application, I'd suggest doing the formatting on the application side. That way the number stored in SQL Server is still a number if you want do addition, aggregation, or other calculations. If you really have to store it as 012345, you need to convert it to a character field; char, varchar, nvarchar, nchar.
For Details
I have a column where I want to write down numbers, but the numbers are long, 25 characters, and I could miss type it so at least knowing that I have typed the correct amount of characters would be helpful.
When typing in Google spreadsheets, I can validate the answer of a column within another column by using: '=IF(LEN(B1)=25,B1,"wrong number of digits")'
which means it would return the cell value if has 25 characters, but if its any other amount it will say wrong number, yet I need to use another column...
Is there any way that while I am typing in a cell it would let me proceed if right number of characters or give an error if I have wrong number of characters, in the same column?
UNTESTED
Please try a Data, Validation..., rule of:
=and(B1>999999999999999,len(B1)=25)
I have added a field to a Payroll Interface definition. I am using the delivered field TEXT254. The field where you define the length of the field in bytes (field definition table) is three characters, so it would appear that you can define the length as 999 bytes. The PI process fails when I set the length to 999 bytes, until I lowered it to 150 bytes. I am experimenting, with it, slowly increasing the value I'm wondering if anyone knows what the limit really is? Our PI takes 3 hours to run, so experimenting takes a long time.
edit - I cut down the runtime by getting rid of all but one company. The largest byte size that I seem to be able to get to run is 240. I did some research, and it looks like when you build your tables, Oracle will set the field to VARCHAR2(n*3) where n is the size of the field specified in AppDesigner. Sure enough, the script generated by the Project...Build sets my field to VARCHAR2(762).
This is what I found - the data that the PI exports is pretty much unlimited - in the PI_PARTIC_EXPT table, the EXPORT_ROW field is 250 characters. If the row you're exporting exceeds this, a new row is inserted with a new sequence number (export_seq), and the data is continued in the EXPORT_ROW field in this new row.
There is,however, a limit to an idividual field that the PI can handle, and that is 240 characters, so once I limited the field to 240 characters all was well.
I'm building a database of a very important state institution. So far, for Primary Key columns I've sometimes used numbers, particularly int32 or int64, and sometimes I've used char but still I stored only numeric characters. Since this a very crucial task I have to make it both performance and comfort-wise efficient. Now I want to know,if it makes any difference to use number or char for a PK column considering the values in the char column will still be numeric characters.
P.S.You might wonder what the point is in using char if I anyway store numeric characters. The reason is becuase the PK column is composed of many parts, like 3 characters for country, 3 characters for province,3 characters for city and 6 characters for a person. And besides that I can make string operations on those columns without worrying about explicit conversion.(I know there's implicit conversion in Oracle but it's discouraged to rely on it.)
Neither as such.
Your primary key should be a surrogate. Int or big int, Guid if scaling is going to be an issue.
Then you should have country, province, city and person as a unique compound key. The 'intelligent' number thingy is rarely a good idea.
integer data type commonly used for primary key because it give better performance for data indexing than varchar. If you need another unique key like combination of characters, you can add it beside primary key marked as unique.
Another important reason, for me, to use generic data for primary key like integer or GUID is for flexibility. For example, you can use email address as primary key of user table. but few days later, when you need to change your application rule that one user can have more than one email address. you will get it more difficult to change you data structure.
just wondering does anyone in here have good idea about generating nice order id?
for example
832-28-394, which show a quite nice and formal order id (rather than just use an database auto increment number like ID=35).
the order id need to look random so it can not be able to guess by user.
e.g. 832-28-395 (shoudnt exist) so there will always some gap between each id.
just like the account number for your bank card?
Cheers
If you are using .NET you can use System.Guid.NewGuid()
The auto-incremented IDs are stored as integer or long integer data. One of the reasons for this is that this format is compact, saving space, including in indexes which are typically inclusive a primary key for use with joins and such.
If you wish to create a nice looking id following a particular format syntax, you'll need to manage the generation of the IDs yourself, and store these in a "regular" column not one that is auto-incremented.
I suggest you keep using "ugly looking" ids, be they auto-incremented or not, and format these value for display purposes only, using whatever format you may desire, including some format that use the values from several columns. Depending on the database system you are using you may be able to declare custom functions, at the level of the database itself, allowing you to obtain the readily formatted value with a simple query (as in
SELECT MakeAFancyId(id_field), some_other_columns, ..
FROM ...
If you cannot use some built-in or custom function at the level of SQL, you'll need to format the value supplied by SQL (an integer of sorts), into the desired format, on the client-side, using the language associated with your UI / presentation framework.
I'd create something where the first eight numbers are loosely in a pattern, and a third quartet looks random but is really a sort of checksum.
So, for example, the first eight digits increment based on the current seconds on the server clock.
The last four could be something like the sum of the first four, plus twice the sum of the second four, which will give either a two or three digit number. The final digit is calculated so that the sum of all 11 digits plus this last one is a multiple of 9.
This is slightly akin to how barcode numbers are verified. You can format the resulting 12 digits any way you want, although it is the first eight that are unique here.
Hash the clock time.
Mod by 100,000 or something.
Format with hyphens.
Check for duplicates. If found, restart.
I would suggest using a autoincrement ID in the database to link tables and as a primary key. Integer fields are always faster than string fields for indexing and well as searching.
You can have the order number field (which is for display) as a different field in the order table which will be used to display. And whenever you are planning to send a URl to a user or display a URL to the user which has order ID (which is a autoincremented number) you can encrypt it with some algorithm.
Both your purpose will be solved.
But I suggest not to make string as primary key. Though you can have a unique constraint on the order number which is going to be displayed.
Hope this helps.
Kalpak Luniya
I would suggest internally you keep the database derived primary key, which is auto-incremented.
For the visible order number, you will probably need a longer length than 8 characters, if you are using this for security.
If you are using Ruby, look at SecureRandom, which will generate sufficiently random strings to accomodate this. For example, you can use SecureRandom.hex(16), and it will give you a 16 digit hex number. I believe it can also give you base 64 strings, which will look weirder but be shorter.
Make sure this is not your only security on an order, as it may not be that hard to find a valid order number within your 8 digit code, especially if some are some sort of checksum.
For security reasons i suggest that you should use Criptographicaly secure random number generator. Think about idea on icreasing User Id length -if you have 1 million users then the probability to gues User ID in first try is 0.01 and 67 tries to increase probability over 0.5