В настоящее время новый баланс отображается в «txtNewBalance», однако он не обновляется в самой базе данных и, в свою очередь, не может использоваться на отдельной странице депозита, поскольку отображается исходный баланс, а не обновленный баланс после снятия части баланса.
Я не вижу txtNewBalance
в вашем коде, поэтому я не уверен, как вы получаете и поддерживаете значение этого элемента управления. Я полагаю, что это другая форма, которая может быть немодальной и, возможно, не синхронизированной c с деятельностью, выполняемой в других формах.
Код в целом выглядит не очень безопасно, и я вижу много возможности для go неверны.
Меня беспокоит этот бит кода:
If txtOutput.Text = "" Or txtOutput.Text = "0" Or txtOutput.Text >= 300 Then
MessageBox.Show("Invalid amount")
txtOutput.Clear()
End If
Здесь вы проверяете txtOutput
, но даже если введенное значение неверно, остальная часть кода, тем не менее, будет выполнена. MessageBox
приостанавливает выполнение, но не завершает его. Если вы хотите остановить выполнение, вы должны добавить Exit Sub
сразу после txtOutput.Clear()
. Я думаю, что это то, что вы хотели. Здесь происходит то, что вы все равно продолжаете и обновляете AccountDataSet
, несмотря ни на что, и вы тоже изменяете txtNewBal
. Я не уверен насчет окончательного результата, но, скорее всего, он ошибается. Это может быть вашей проблемой, и она может быть не единственной.
На самом деле, эта проверка некорректна, потому что вы тестируете только для 3 указанных c условий, но может произойти еще много: просто подумайте о пробелах или о чем-то еще.
Для дальнейшего уточнения возможных проблем безопасности рассмотрите этот код в функции Retrieve
:
txtAccountNum.Text = frmLogin.EmployeeNO
Лучшим способом было бы определить EmployeeNO
как глобальную переменную сразу после входа в систему и передать эту переменную как параметр в вашу функцию, а не повторно проверять другую форму для получения этого значения.
Представьте, что после входа в систему злоумышленник возвращается к форме входа и изменяет значение EmployeeNO
(предположительно, текстовое поле). Ваша функция Retrieve
будет использовать новое значение, которое может быть значением другого сотрудника.
«Обычно», этого не должно происходить. Но вы используете функцию Show
для своих форм, а не ShowDialog
, что означает, что ваши формы не являются модальными . Если в вашем коде есть изъян и по какой-то причине Hide
действительно не работает, вы можете оказаться в ситуации, когда одновременно видно более одной формы, и можно переключиться с одной формы на другую, чтобы обмануть вас. приложение, чтобы делать плохие вещи.
Другие замечания:
Во всех случаях я настоятельно советую записать все действия в файл. Важно сохранять след активности , особенно когда речь идет о деньгах или реальных товарах.
Будете ли вы вести бизнес с банком, который не может объяснить, где и когда вы сняли деньги с Ваша учетная запись?
Любые изменения должны быть зафиксированы в базе данных немедленно. Не храните изменения в наборе данных дольше, чем это необходимо. Хранить данные в памяти слишком опасно. При отключении питания вы можете потерять данные, и ваши учетные записи могут оказаться в несогласованном состоянии.
Если вам нужно обновить более одной записи, важно использовать транзакций для сохранения целостности ваших данных. Представьте, что вы кредитуете одну учетную запись, но ваш код дает сбой, прежде чем вы сможете вычесть соответствующую сумму из исходной учетной записи. Вы остались с большим расхождением в ваших аккаунтах. Что еще хуже, это неспособность объяснить, откуда возникло несоответствие.
Относительно проверки ввода пользователя в ваш код: действительно ли вы используете обычные текстовые поля? Лучшей альтернативой будет элемент управления NumericUpDown . Он ведет себя как текстовое поле, но ограничивает ввод числами в диапазоне, который вы можете определить заранее. Это также немного улучшает ваш интерфейс.
Вы даже обрабатываете исключения в вашем коде?
Подводя итог, вот некоторые вещи, которые вы, возможно, захотите сделать:
- улучшить методы проверки
- выбрать лучшие элементы управления пользовательским интерфейсом для задания
- log все
- имеют строгую обработку исключений - если сомневаетесь, остановите свое приложение, а не рискуете сделать что-то не так
- возможно, прочитайте несколько учебных пособий, потому что многие люди делали подобные вещи, и нет необходимости заново изобретать колесо каждый раз. Только в Stack Overflow имеется множество проверенных кодов, не говоря уже о репозиториях, таких как Github, где вы можете увидеть, как создаются приложения. Вы можете черпать вдохновение из вещей, которые существуют. Я сам многому научился, просто наблюдая за более опытными разработчиками. Важно выучить лучшие практики на ранних этапах, а не вырабатывать вредных привычек , которые всегда будут вас раздражать.
Приложение для банкомата звучит как серьезный материал, особенно если вы собираетесь работать количество людей, и вы не единственный пользователь. Вы не хотите злить их. Вы, конечно, не можете позволить себе быть неряшливым. Так что не торопитесь и документируйте себя. Удачи.