Re: Connection string
Posted: Wed Oct 12, 2016 10:08 am
As declared by livecode, It's a bug, driver is missing in all commercial versions from 7.1.2. 
They are investigating
They are investigating
LiveCode Forums
Questions and answers about the LiveCode platform.
https://forums.livecode.com/
Connection string
Page 2 of 2
Re: Connection string
Posted: Wed Oct 12, 2016 11:25 am
MaxV well done for sleuthing this - sounds like you are close to getting it fixed
Re: Connection string
Posted: Wed Oct 19, 2016 8:22 am
How long does it usually take to fix these kind of bugs?
Re: Connection string
Posted: Mon Oct 24, 2016 10:37 am
The LiveCode workflow is a typical git workflow, where contributors fork the livecode/livecode repository, make their changes on a branch, and then submit a pull request.
Setting up git with your user information
Please ensure that your full name and e-mail address are in the git configuration. Ideally, the e-mail address you use with git should be the same as the e-mail address you used to sign the CLA (i.e. the one used for your LiveCode customer account here. You must sign this: https://livecode.com/account/developer/contribute ).
You can set up the name and e-mail address from the command line:
Note: Pull requests which add commits containing incorrect author name and e-mail addresses will be rejected.
Branches in GitHub
You should base your changes on an appropriate branch:
The develop branch is where work on the next major, experimental release of LiveCode takes place. It usually has all of the most exciting new features, but also a lot of bugs to go with them. If you are adding a new feature to LiveCode, submit your changes to this branch.
The develop-X.Y branches work towards the next X.Y.Z release. They are usually much more stable than the develop branch. If you are fixing a bug in LiveCode, submit your changes to the "oldest" develop-X.Y branch that exhibits the bug.
The release-X.Y branches are used as part of the release process. Unless you are helping to make a release, you should not normally work with these branches.
Creating a pull request
When you submit a pull request, please make sure to follow the following steps:
Ensure that all the commits have good log messages, in the following format:
Summary line of less than 80 characters
Explanation of what the commit fixes and why it's the right
fix, possibly using multiple paragraphs. For example, you
might want to describe other options and why the one you
chose is better.
It's very important that readers can get a good idea of what the commit is about just by reading the summary line. To help with this, we use some special "tags" at the start of a commit message summary line:
If the commit fixes a bug, please add [[Bug <bug number>]] at the start.
If the commit relates to a particular new feature — and there are several commits and pull requests involved in the feature — please add [<feature-name>] at the start.
If the commit fixes a Coverity Scan defect, please add [CID <defect number>] at the start.
Make sure that the pull request only relates to one change (one bug fix, one new feature, etc.) or to a group of very closely-related fixes. Please make sure that the pull request has a good description too (often you can base the title and body of the pull request on the commit messages).
Please highlight any areas of your changes that you thought were particularly difficult to figure out. This will help make sure that your code gets thoroughly reviewed.
Pull request process
After you submit a pull request, a member of the LiveCode team will review your changes. They will probably find some improvements that need to be made. Please note that if a reviewer asks you to change your code, it doesn't necessarily mean that there was anything wrong with the changes you've made. It often means that they have spotted a way to fix other things at the same time, or to make your change fit in better with other things that are being worked on elsewhere.
Once a reviewer is happy with the changes, they will mark the pull request as reviewed. The LiveCode continuous integration system will then take your code, and automatically build & test it on all of the platforms supported by LiveCode.
If the tests don't pass, then you will need to make some more changes to fix the problems that were found. These will then be reviewed, etc.
Once your changes have been reviewed and tested, they will be merged in time for the next release.
Setting up git with your user information
Please ensure that your full name and e-mail address are in the git configuration. Ideally, the e-mail address you use with git should be the same as the e-mail address you used to sign the CLA (i.e. the one used for your LiveCode customer account here. You must sign this: https://livecode.com/account/developer/contribute ).
You can set up the name and e-mail address from the command line:
Code: Select all
git config --global user.name "<your name>"
git config --global user.email "<your email address>"Branches in GitHub
You should base your changes on an appropriate branch:
The develop branch is where work on the next major, experimental release of LiveCode takes place. It usually has all of the most exciting new features, but also a lot of bugs to go with them. If you are adding a new feature to LiveCode, submit your changes to this branch.
The develop-X.Y branches work towards the next X.Y.Z release. They are usually much more stable than the develop branch. If you are fixing a bug in LiveCode, submit your changes to the "oldest" develop-X.Y branch that exhibits the bug.
The release-X.Y branches are used as part of the release process. Unless you are helping to make a release, you should not normally work with these branches.
Creating a pull request
When you submit a pull request, please make sure to follow the following steps:
Ensure that all the commits have good log messages, in the following format:
Summary line of less than 80 characters
Explanation of what the commit fixes and why it's the right
fix, possibly using multiple paragraphs. For example, you
might want to describe other options and why the one you
chose is better.
It's very important that readers can get a good idea of what the commit is about just by reading the summary line. To help with this, we use some special "tags" at the start of a commit message summary line:
If the commit fixes a bug, please add [[Bug <bug number>]] at the start.
If the commit relates to a particular new feature — and there are several commits and pull requests involved in the feature — please add [<feature-name>] at the start.
If the commit fixes a Coverity Scan defect, please add [CID <defect number>] at the start.
Make sure that the pull request only relates to one change (one bug fix, one new feature, etc.) or to a group of very closely-related fixes. Please make sure that the pull request has a good description too (often you can base the title and body of the pull request on the commit messages).
Please highlight any areas of your changes that you thought were particularly difficult to figure out. This will help make sure that your code gets thoroughly reviewed.
Pull request process
After you submit a pull request, a member of the LiveCode team will review your changes. They will probably find some improvements that need to be made. Please note that if a reviewer asks you to change your code, it doesn't necessarily mean that there was anything wrong with the changes you've made. It often means that they have spotted a way to fix other things at the same time, or to make your change fit in better with other things that are being worked on elsewhere.
Once a reviewer is happy with the changes, they will mark the pull request as reviewed. The LiveCode continuous integration system will then take your code, and automatically build & test it on all of the platforms supported by LiveCode.
If the tests don't pass, then you will need to make some more changes to fix the problems that were found. These will then be reviewed, etc.
Once your changes have been reviewed and tested, they will be merged in time for the next release.
Re: Connection string
Posted: Wed Nov 23, 2016 8:08 am
I don't think it is fair to pay for a crucial feature that is not there.
Re: Connection string
Posted: Wed Nov 23, 2016 2:02 pm
I suppose that you can ask a refund or a free upgrade.
It wasn't clear on livecode page that Indy doesn't include the oracle driver.
It wasn't clear on livecode page that Indy doesn't include the oracle driver.
Re: Connection string
Posted: Tue May 16, 2017 7:20 pm
Unfortunately there's still no fix from LiveCode team. 
Re: Connection string
Posted: Tue May 16, 2017 7:31 pm
interesting, I thought I've seen a report of a bug fix for this (in the last couple of months? anyone else remember this?)
EDIT:
Ah I see now that it's for Indy and Business licence holders...
EDIT:
Ah I see now that it's for Indy and Business licence holders...