Leaderboard

AlMax3000, Please try and keep a civil tongue here. This is not the first time I have seen you react badly to offered advice - please make it the last. M23

Stabs without the script source and more details: Better error checking to ensure the IniReadSection() function actually worked? Better checking whether $aArray exists and is actually an array? Jos

Please read my posts from the thread https://www.autoitscript.com/forum/topic/201647-solved-zipping-folders-from-the-path-given/ When you use 7zG.exe, you will get a progress window.

@water IMO I believe you should add this as its a state with in the email format and will also keep your outlookEX UDF up to date

I just noticed that ReplyRecipients are missing in the OutlookEX UDF. Is this something I should add?

You need to add a COM error handler to your script to get better error information. Please check ObjEvent in the help file.

In general you use data binding in SQL statements to avoid SQL injection by adversaries. https://xkcd.com/327/ I've posted here a set of functions for binding for SQLite but that slows down things significantly, due to numerous use of DllCalls and glue code. Binding should be reserved for fast (compiled) languages like C, not slow (interpreted) like AutoIt. Yet AutoIt + SQLite is more than enough for your use case. That leaves you with building your SQLite statements with SQL parts and inlined values, mostly variables, of different types. You often have to escape strings (double single quotes in strings) using _SQLite_FastEscape() if you suspect they might someday contain '. Use _SQLite_FastEncode() for binaries. You also have to take care of enclosing strings in single quotes (double quotes are reserved for schema names like table or column names containing spaces or ") and insert commas between second and next arguments (i.e. in insert statements). That makes typing statements a little painful. I personally use a set of little functions to make that much less error-prone. To use that you need to remember that SQLite understands 4 basic datatypes which end up in only 3 here: Text, Int or Real (Numeric) and Hex. The first literal parameter doesn't need a leading comma, but next ones do. So the rules for using this set of functions is: for first parm, use single letter function with 1 appended, use single letter functions for subsequent parameters. Consider the insert statement previously posted: Local $StdStr = "INSERT INTO MeterReadings(Meter,Date,Time,Reading,Error) VALUES(" $sSQL = $StdStr & "1,'" & $Date & "','" & $Time & "',194.0,'Y');" $Result = _SQLite_Exec(-1, $sSQL) A single error in the mixup of " ' , results in an error. Hard to type when you have dozens of literal values of various types. I understand that your use case is simple, but anyway. Here's the list of functions: ; for the first parameter only Func N1($v) Return (Number($v)) EndFunc ;==>N1 Func T1($v) Return ("'" & StringReplace($v, "'", "''") & "'") EndFunc ;==>T1 Func B1($v) Return ("X'" & Hex($v) & "'") EndFunc ;==>B1 ; for subsequent parameters Func N($v) Return ("," & Number($v)) EndFunc ;==>N Func T($v) Return (",'" & StringReplace($v, "'", "''") & "'") EndFunc ;==>T Func B($v) Return (",X'" & Hex($v) & "'") EndFunc ;==>B N1() and N() are for Numeric (int or real) T1() and T() are for Text B1() and B() are for Binary N, T & B are very intuitive as type mnemonics and you just have to remember to use N1, T1 or B1 for the 1st parm. Here's the same statement rewriten using them: Local $StdStr = "INSERT INTO MeterReadings(Meter,Date,Time,Reading,Error) VALUES(" $sSQL = $StdStr & N1(1) & T($Date) & T($Time) & N(194.0) & T('Y') & ")" $Result = _SQLite_Exec(-1, $sSQL)

For the rowid (= meaningless "record number") you don't need autoincrement (unless you expect rowids numbers in the vincinity of 2^63 - 1), you don't need not null (because the PK here is type INTEGER) and you certainly don't need unique (which creates a needless duplicate "unique" index (PK can't be non-unique with a historical exception in SQLite for PK of types not INTEGER [distinct type from INT] where NULLs are always distinct). Any SQLite (SQL) table must have either an implicit rowid or a rowid alias in the form of a column like ID of type INTEGER declared as primary key. The difference between int and integer is specific to SQLite. Also SQLite doesn't honor declared sizes of column: char(14) is the same as char and you can store Mb of text in it. The type system of SQLite is flexible: you can store any type in any column except the rowid or rowid alias (INTEGER type). Declaring a type for a column is only an indication for what SQLite calls affinity. In an int[teger] column, you can input '123' and since the conversion to int is lossless, then SQLite will store 123 as int. ' 123' can't be stored losslessly (leading space) and will store as text ( = char). Else you can declare a column of type you call humour and all is fine. This "type" is unknow and no attempt at conversion will occur, no error either. This type system fits AutoIt variants well enough for most purpose, but you can always force storage of only controlled types by using check contraint(s) or trigger(s). You don't need to provide a value for an Id of type integer either in your inserts, except if you declare ID in the list of columns to insert (even then you can provide Null and it will create a new unique id for you). You can use create table if not exists blah ... which won't error out if the table blah already exists. You probably should merge date and time columns and specify default CURRENT_DATETIME: SQLite date/time are UTC and that makes them universal. You can manipulate timestamps to convert to local time, or whatever. Prefer the format YYYY-MM-DD since it's the format used by internal datetime functions, contrary to _NowDate() which uses YYYY/MM/DD. I anticipate you'll be extracting data based on timestamps and meter# so better use the format SQLite can manipulate inherently. It's always easy to convert to another format for display, outside the storage engine. The error column looks like binary or even ternary logic (Y/N/don't know). Hence you can store it as int (regular 0=N, 1= Y, Null if don't know) as SQLite stores and handles these values in a special format.

I really wasted time here, insignificant answers for brain-damaged children